Posts on Brewed in the Cloud by Chris Hailes

WAF, Firewall, DDoS or Network Security Perimeter? Choose by Threat Boundary

Thu, 05 Nov 2026 00:00:00 +1100

“Should we use WAF, Firewall, DDoS Protection or Network Security Perimeter?”

Before choosing, I would ask what we need to stop. An unwanted web request, an outbound connection, public access to a PaaS resource and an availability attack are not the same failure. Treating them as one purchasing decision is how a team ends up with the right product for the wrong problem.

A WAF rule can reject a web request while an unintended data operation remains available. DDoS protection can improve resilience against network-layer attacks without narrowing a workload’s data permissions. A perimeter association can be present while its enforcement mode is not the mode the design assumes.

Choose the boundary first. The threat-to-control matrix below makes the choice concrete: what the control should change, what it cannot replace, and how to check the difference without generating an attack.

The Mental Model

Controls are comparable only when they address the same failure condition.

Different layers can be complementary without being alternatives.

The continuing illustrative scenario has a public application ingress, an application workload, approved private Storage access, and a controlled unintended destination. Identity, networking and service behavior determine what can be done after a request reaches the application.

Split the review into four questions. Which HTTP requests should reach application logic? Which connections should the workload establish? Which public relationships should a supported PaaS resource accept? What protects the public endpoint’s availability under a network-layer attack?

Now the controls have a job to do. They are no longer competing on a feature list.

flowchart LR E[Public client] --> W[Application request boundary] W --> A[Application workload] A --> F[Selected network enforcement path] F --> D[Destination operation] I[Identity and service authorization] --> D P[Supported PaaS public-access boundary] --> D V[Availability resilience] -. supports .-> W

This is a boundary map, not a promise that every packet crosses every product. Private traffic may follow a different route from public traffic, and service-side operations may have another boundary entirely.

How It Really Works

Use a threat-to-control matrix

The draft toolkit’s threat-to-control module records threat, source, operation, candidate control, enforcement placement, unsupported cases, evidence and operational burden. A useful starting point is:

Failure condition	Candidate boundary	What it does not establish
Unwanted HTTP request reaches application logic	WAF policy on the chosen supported application front end	Correct application authorization or workload egress restriction
Unwanted connection leaves a source along an inspected route	Azure Firewall rules for traversing traffic	Enforcement on alternate routes or correct destination permissions
Unwanted public access to an onboarded PaaS resource	Network Security Perimeter association and applicable access rules	Blocking every Private Endpoint operation
Network-layer flood threatens an eligible public endpoint	Appropriate Azure DDoS offering	Prevention of authorized data misuse or all application-layer overload

Microsoft’s current documentation distinguishes WAF application protection from DDoS layer 3/4 protection. Firewall rule processing separately distinguishes DNAT, network and application rules. NSP documentation describes supported PaaS associations, transition/enforced modes and public-access rules.

Use those distinctions to decide what belongs in the design. Combining the products does not remove the need to check each one’s actual scope.

Verify placement, mode and bypass

For WAF, identify the hosting product and SKU, attached policy, effective mode and protected route to the origin. Detection-mode evidence is not prevention evidence. Confirm the exact host-specific capability before choosing a managed rule set or custom rule.

For Firewall, establish that the relevant route traverses the appliance and inspect effective policy, including parents and broader rules. A narrow application rule cannot rescue a matching permissive network rule that already terminates evaluation.

For NSP, inspect the resource association and supported service. Microsoft’s documentation allows Private Endpoint traffic without explicit NSP access rules; do not treat an enforced perimeter as a universal private-data boundary. Resource authentication and authorization still need their own assessment.

For DDoS, identify the eligible public IP/resource, selected offering and evidence of enabled coverage. Public-cloud feature availability does not imply every PaaS integration has identical support. Check service-specific support and cloud/region constraints.

Exercise a composition safely

Use a harmless marker header or path to match a deliberately configured WAF test rule on an author-owned application. Compare the front-end request with an authorized direct-origin check. The expected result is a documented policy response, not proof that all malicious requests are blocked.

Separately test a non-HTTP connection along the declared Firewall path and a synthetic authenticated operation against the controlled destination. Record which boundary rejects each case. A blocked HTTP marker alongside a successful unintended Blob operation is a useful counterexample: WAF works at its boundary while the consequence remains elsewhere.

DDoS validation here is configuration and coverage review only. Do not generate attack traffic or label a benign load test a mitigation result. Provider-authorized simulation would be a separately scoped exercise.

Real-World Impact

The matrix changes procurement and engineering reviews because each control must justify its role in a particular path. More layers are not automatically more assurance.

Prefer the composition that preserves necessary work

An application might need WAF protection for public HTTP input and tightly scoped data roles for Storage operations. An egress restriction may then constrain additional destinations. DDoS coverage addresses a distinct availability pressure where the endpoint is eligible.

Before adding another layer, ask which remaining operation it will constrain. TLS inspection can bring certificate management, troubleshooting and cost without correcting the broad data role that authorizes the unwanted write. It may still be justified, but that role is not a reason to deploy it.

Make ownership part of selection

WAF exclusions, Firewall policy inheritance, NSP profiles and service roles may have different owners. A control without an owner for changes and failure response becomes another exception backlog.

I would choose a smaller composition the team can test and operate over a wider one nobody can explain during an outage. An exclusion waiting for approval, a certificate renewal and an ambiguous support handoff all consume attention. That cost belongs beside the Azure bill.

Gotchas and Edge Cases

The awkward cases are worth keeping in the review. They show how a control can work correctly while the finding remains unresolved.

Origin access can bypass the web boundary

A front-end WAF result says nothing about an independently reachable origin. Inspect origin restrictions and allowed legitimate management paths before asserting that application input is constrained.

A network allowance is not a business allowance

Permitting HTTPS to a destination does not establish that the destination account, tenant or operation is approved. A successfully authenticated write can remain an unintended relationship even when every packet follows the designed route.

Transition evidence is not enforced rejection

NSP transition mode helps understand existing access patterns. Its presence is not proof of enforced denial. Record effective association mode and test resource-specific behavior rather than rely on the word “perimeter.”

Availability controls have their own exclusions

DDoS offering eligibility and value-added features differ. Do not transfer a coverage claim from one public IP resource to every public endpoint in the architecture. A dependency outage or valid application overload can also remain outside the tested protection.

Best Practices

Give each failure condition its own matrix row, with a non-goal and a counterexample. If two products answer different questions, do not force them into a winner-and-loser comparison.

An application owner should be able to read the result as a decision: “We need this boundary because of this operation, and we accept this remaining limitation.” That is more useful than a diagram carrying four security logos.

Assumptions and evidence boundary

These are documented control distinctions and proposed exercises, not observations from a combined tenant deployment. Before testing, record hosting/SKU and mode for WAF; Firewall tier, rule types and route; NSP onboarded resource, association API/schema and mode; DDoS offering and eligible endpoint; actual region/cloud support and diagnostic categories. Deployment APIs remain unpinned until a supported template and authorized lab are selected.

Separate permissions for reading policy/configuration, changing it and performing service data operations. Testing with an administrator can conceal the authority boundary the workload actually has.

For this finding, I would require every added control to constrain a named unwanted operation or support a named availability/recovery requirement. If it does neither, leave it out of this remediation decision. Any retained exception needs an owner, expiry and a compensating boundary we can actually test.

🍺

Brewed Insight: Choose controls by the question they answer. A control that works exactly as documented can still be the wrong response when the consequence sits at a different boundary.

Learn More

From Finding to Path: Model Azure Exposure as Reachability

Tue, 03 Nov 2026 00:00:00 +1100

A finding can land at the top of the queue and still leave the engineer guessing.

“Restrict access to this storage account” sounds actionable. But access from where, using which identity, to do what? Without those answers, two teams can implement different fixes and both reasonably believe they have finished.

The earlier attack-path prioritization article explains why consequence should outrank finding volume. This series starts after that decision: what exactly should change, and how will we know the change worked?

I would not hand that finding to engineering until we can name the path and explain how the fix could fail its test. That adds work to triage. It also avoids the more expensive conversation later: the setting changed, so why is the unwanted operation still possible?

The Mental Model

Start with what the compromised workload can do, not where it sits on the diagram. An exposure path connects that capability to usable authority, a network path, a destination operation and its consequence.

Consider an application spoke whose workload needs to read objects from an approved private Blob destination. A second controlled destination represents somewhere it should not write. DNS, telemetry and responder access must keep working when we constrain that second path. This illustrative scenario runs through the series; the testing assumptions are collected below.

Can the workload connect to the second account? That is one question. Can its identity actually write there? That is another. And if we block the connection, can the workload or its deployment pipeline change a role assignment, public access setting or route to reopen it?

Those questions belong in the same record. Otherwise we risk closing the door while leaving the means to unlock it untouched.

flowchart LR S[Source workload capability] --> I[Effective identity authority] S --> N[DNS and network path] I --> O[Destination operation] N --> O O --> C[Reachable consequence] M[Control-plane change authority] -. can reopen .-> N M -. can widen .-> I R[Recovery and telemetry dependencies] --> V[Validation boundary]

The diagram expresses dependencies, not an Azure packet-processing order. A useful record names which edge a proposed change will constrain and which edges remain.

How It Really Works

Make the finding an engineering hypothesis

Give the path a stable ID, then describe it plainly: this workload, using this principal, can perform this operation against this service instance. Add the DNS answer, route and authorization scope that make the operation possible. Include who can change those conditions, not just who owns the account.

Then write a claim that can fail:

After change C, source S using principal P cannot perform operation O against controlled destination D; the approved dependency and responder path still work.

That is less impressive than “the account is secure.” It is also something an engineer can challenge, implement and test.

The path-record module in the draft Azure Exposure Reduction Toolkit provides the technical companion. Its minimum fields are:

Field	Decision it supports
Path ID and scope version	Comparing the same case across changes
Source, principal, destination, operation	Establishing which capability is being constrained
DNS, route and enforcement context	Identifying where the network claim applies
Role scope and control-plane owner	Finding authority that can preserve or reopen access
Expected result and evidence references	Separating a hypothesis from a supported conclusion
Positive controls, residuals and retest triggers	Preserving service and avoiding permanent assurance claims

Inventory gives you a starting point, not a verdict. This read-only Azure Resource Graph query identifies declared Private Endpoint targets:

1
2
3
4
5
6
7
8


resources
| where type =~ "microsoft.network/privateendpoints"
| mv-expand connection = properties.privateLinkServiceConnections
| project endpointId = id,
 subnetId = tostring(properties.subnet.id),
 targetId = tostring(connection.properties.privateLinkServiceId),
 groupIds = connection.properties.groupIds,
 location

Run it in Resource Graph, not a Log Analytics workspace. It covers the automatic connection property shown; manually requested connections use a different property and need separate inspection. Empty output may mean missing scope, permissions, delayed inventory or no matching resources. It does not mean no usable path exists.

Test authority and reachability separately

Run the checks where the workload runs. A successful CLI call from an administrator’s laptop may use a different resolver, route and identity. It answers a useful question, but not necessarily the one in the finding.

Use synthetic objects and scoped data permissions. The baseline must include an authorized, harmless operation that succeeds against the controlled unintended destination if the claim is that this path currently exists. If baseline access fails, investigate why; do not celebrate the same failure after the change as newly achieved reduction.

After a single approved lab change, repeat the identical operation, approved dependency probe and responder-access check. Preserve request identifiers, timestamps and configuration versions. A negative result is convincing only when the positive controls still work and the rejection can be attributed to the intended boundary.

Real-World Impact

The useful handoff is no longer “secure Storage.” It is “remove this write capability without breaking that read dependency.” Platform, identity and application owners can then divide the work without pretending one team owns every part of the path.

Choose the smaller defensible change

Suppose the application needs reads from account A but has inherited write authority to account B. Tightening the data role may be a smaller change than introducing a new centralized inspection dependency. Conversely, network restriction may be valuable where many identities share a reachable management surface.

I would compare those changes by the capability they remove and the dependency they preserve, not by how much infrastructure they introduce. The record gives the reviewer a way to make that choice and see what remains.

Leave responders something useful

A path record should survive the remediation ticket. During an incident, it tells responders which dependency they can constrain, which identity scope matters, and which recovery operation must remain possible.

That durability is worth the documentation burden when consequence is high. For a low-value isolated endpoint, a shorter record may be proportionate. The method should improve a decision, not create an exhaustive graph project before every change.

Gotchas and Edge Cases

A neat record can still describe the wrong path. The most important checks are the ones that catch a convincing explanation before it becomes a closure decision.

Reachable does not mean authorized

A successful TCP connection establishes transport, not Blob write authority. A service rejection might reflect authentication, authorization or a network policy; retain service error details rather than assigning every 403 to the firewall.

A snapshot can miss reopening authority

The principal used by the workload may not itself edit networking, while its deployment pipeline can. Record the separate automation identity and who can change that pipeline. The relevant authority graph includes deployment and recovery operations.

Context changes invalidate comparison

Changing resolver, test principal, destination subresource or token state between runs changes the experiment. Cached tokens and sessions require explicit handling. Use fresh connections and record token-acquisition context without recording tokens.

Unknown paths are not blocked paths

If role visibility or diagnostic access is incomplete, mark the path unknown. Removing an unknown record from the denominator does not improve security. It only improves the appearance of the report.

Best Practices

Start with the highest-consequence finding that has a controllable test boundary. Define one source, one principal, one destination operation and one proposed intervention. Expand only after the first record can be reviewed and reproduced.

Assumptions and evidence boundary

The proposed exercise uses synthetic objects and author-owned Blob destinations on supported general-purpose v2 Storage accounts. Service data access is separate from management-plane read access. Resource Graph needs visibility over the queried resources; the operation needs the appropriate scoped data role. Confirm CLI version, effective-route inspection support, resource API versions, region availability and diagnostic schema for the selected topology before deployment.

Microsoft documents Private Endpoint connectivity and unchanged service authorization mechanisms. This article proposes a validation exercise; it does not report Azure lab results. Keep those evidence categories separate in the final record.

I would close this as a removed path only when the baseline existed, the unwanted operation fails at the intended boundary, required service still works, and reopening authority is accounted for. If one of those is missing, call it a partial change or an inconclusive test. That is a useful engineering result too; it just is not the result we set out to prove.

🍺

Brewed Insight: A good remediation claim names the capability that disappears and the dependency that survives. A resource setting without those two statements is still an implementation task, not evidence of reduced consequence.

Learn More

Prove the Attack Path Is Broken

Thu, 29 Oct 2026 00:00:00 +1100

The change ticket says “removed excessive access.” The role assignment is gone, the route was updated, and the review is marked complete.

What changed for the workload?

That question is not answered by the ticket status. A control-plane diff proves a configuration changed. It does not establish which identity the process uses now, where its hostname resolves, whether the service accepts the request, or whether an alternate path survived.

If the claim is that an attack path is broken, the evidence needs to include a test of that claim.

The Mental Model

A useful before-and-after comparison holds the test conditions steady while changing one known edge. For a workload-to-service path, record:

the source process and identity;
the target operation;
the service name and resolved destination;
the network protocol and port;
the identity/network configuration change;
the request result before and after.

flowchart LR W[Same workload context] --> I[Same identity under test] W --> D[Same DNS question] D --> P[Observed destination] P --> S[Same service and operation] C[Scoped control change] -. changes authority or reachability .-> S W -->|repeat comparable test| S

The graph is not an inventory of every possible route. It is a record of the claim you tested and the boundary around that claim.

A control is a proposed explanation. The before-and-after request is evidence of its effect.

How It Really Works

Write the claim so a failed test can disprove it

“We reduced attack paths” is not falsifiable. Try: “After removing the Blob data permission from principal A at scope B, workload C can still read its required test object, but cannot read the prohibited test object through hostname D.”

That claim names an allowed operation and a denied one. It also avoids equating application outage with security improvement. If the required read fails too, the change may have removed the dependency rather than narrowed it.

For a network change, specify the source, destination, protocol/port, and expected result. “Private Endpoint works” needs more detail: which service hostname, resolver context, address, and client operation? If the destination is a VM, name the listening port and test type. Record whether the source is the actual workload, a VM diagnostic, or a separate probe.

Capture the baseline before changing anything

Use a read-only, non-sensitive test object and an authorized environment. Capture the principal used by the workload, the requested operation, DNS answer from the workload’s resolver path, destination address used by the client, and connection/service outcome. Store tokens nowhere in the evidence pack.

Inspect the relevant configuration as well: role definition and assignment scope, identity attachment, DNS zone/links/forwarding, routes, NSGs, firewall policy, and target service restrictions where applicable. Include only the surfaces that affect this path. A sprawling export makes it harder to see the edge you intend to test.

Record time and versions. For Azure RBAC Role Assignments REST API, use a supported API version and include conditions when relevant; 2022-04-01 supports conditions. For Network Watcher, record current source support, region enablement, diagnostic mode, and required permissions. Neither tool replaces the application’s actual request.

Change one edge when practical

If you remove an identity assignment and simultaneously alter DNS, routes, and firewall policy, a failed request tells you the path changed, but not which change mattered. Incident containment may require several actions at once; a controlled architecture test should isolate the change where practical.

Keep the control-plane diff and the data-plane result separate. The diff is evidence of intent and scope. The request result is evidence of observed behaviour under test. If they disagree, investigate rather than choosing the more convenient one.

Retest the allowed and denied cases

Repeat the required operation from the same workload context. Then try one carefully selected operation or object that should remain denied. Keep the same source, identity, hostname, and protocol unless the change intentionally alters them. If the path is supposed to be unreachable, record an actual connection failure plus supporting route/policy evidence.

Do not claim “all access is gone” from one denied read. It says that request failed in that context and at that time. The service may have other data operations, identities, DNS answers, or network paths that were not part of the test.

Real-World Impact

The value of the evidence pack is not a more impressive audit trail. It is preventing the team from shipping a security change that simply moves the failure somewhere less visible.

For example, a role change might cause the target read to fail while the application falls back to a public endpoint and a different credential. If the only retest is “the app still works,” the path may be less contained than before. Conversely, a TCP failure from a diagnostic source might be caused by the target not listening, while the actual workload remains able to reach it through a proxy.

Use one compact record per claimed path:

Record item	Before	After
Workload/process and principal	Identified runtime context	Same context or documented change
Operation	Required and prohibited test action	Same actions, same test data
DNS	Resolver and answer chain	Resolver and answer chain
Network	Source, destination, protocol/port, result	Comparable source and test
Change	None or baseline configuration	Exact role/DNS/route/policy diff
Service outcome	Response and timestamp	Response and timestamp
Boundary	Untested sources/targets/operations	Remaining paths and uncertainty

The table does not prove a whole estate is safe. It helps the owner state what improved, what remained available, and what still needs investigation.

Gotchas and Edge Cases

Before-and-after evidence can look objective while quietly comparing different tests. A new token, a different source VM, a changed DNS cache, or a different service operation can alter the outcome without demonstrating that the control worked.

Changes can have propagation and cache effects

Identity authorization, DNS, routes, and connections do not all change on the same clock. Verify the relevant service behaviour and record when each test ran. Do not invent a fixed convergence time or treat the first result after a change as permanent.

A denial can have the wrong cause

A permission error, timeout, DNS failure, and connection refusal are different results. Capture the service error or diagnostic reason. A generic “failed” status cannot tell you whether authority, name resolution, routing, a firewall, or the target itself stopped the operation.

Negative testing needs a safe boundary

Do not probe arbitrary tenant resources to see what else is reachable. Define the allowed and denied test targets in advance, use non-sensitive data, and obtain authorization. The prohibited case should be representative enough to test the control without turning the validation into uncontrolled discovery.

Evidence can go stale

A result applies to the tested configuration and time. New identity assignments, DNS links, endpoint changes, or routes can reopen a path. Decide which changes invalidate the record and who owns the retest. Otherwise, the evidence pack becomes another static diagram.

Best Practices

Keep a durable statement of the claim, the test tuple, the control change, and the result. Store enough information for another engineer to reproduce the request, but never include access tokens or sensitive payloads. Use the same workload context and safe test data before and after whenever possible.

Separate three conclusions: whether the configuration changed as intended; whether the required operation still works; and whether the prohibited path now fails for the intended reason. If any answer is unknown, say so. It is more useful than converting uncertainty into a green status.

Finally, treat the evidence as scoped and time-bound. Re-run it after a relevant edge changes and leave a list of untested identities, destinations, and operations. “We broke this path under these conditions” is a defensible result. “The workload has no attack paths” almost never is.

🍺

Brewed Insight: The proof isn’t that the role assignment disappeared or the firewall rule changed. The proof is the same workload request, tested again, with the intended dependency preserved and the unnecessary consequence removed.

Learn More

Cut Both Edges: Identity and Network Containment

Tue, 27 Oct 2026 00:00:00 +1100

The incident call starts with a familiar instruction: block the workload.

Block it where? Remove its role? Disable its identity? Deny its subnet? Isolate the VM? Each action sounds like containment until you ask what the other half of the path can still do—and which production dependency you just cut along with it.

When an application is compromised, the objective is not to demonstrate that someone can make a control-plane change. It is to reduce the attacker’s options without losing the services responders still need. That requires an identity decision and a network decision made against the same path.

The Mental Model

For a workload-to-resource path, identity and networking enforce different conditions:

Identity determines which operation the principal can perform at the service.
DNS and network policy determine how the workload locates and reaches the service.
The service and application determine what happens to the request and whether the dependency still functions.

Changing one edge may be the right first move. It does not prove the full path is broken.

There is no universal “revoke first, block second” sequence. The right order depends on confidence, service impact, control-plane integrity, and how quickly the attacker can use the remaining path. That uncertainty should be in the runbook before the pager goes off.

Containment is not complete because a rule changed. It is complete when the tested consequence fell and the required service still behaves as intended.

How It Really Works

Identity-only containment

Removing or reducing an identity assignment can narrow what the principal is authorized to do. Disabling an identity or changing workload configuration may be appropriate when the workload itself is untrusted. These actions do not automatically establish that the process cannot reach the destination, and the operational timing of authorization changes must be verified for the specific service and request.

Identity-only action can be useful when network paths are shared by many healthy services and the suspicious workload’s authority is the clearest edge to remove. It can be less disruptive than blocking an entire subnet. But if the workload has another identity, a cached credential path, or can invoke an intermediary with its own authority, one removed assignment may leave the consequence intact.

Network-only containment

Restricting egress, isolating a VM, changing a route, or applying a narrowly scoped deny can stop a known source from contacting a target. This can buy responders time when they do not yet trust the workload or identity. It may also cut DNS, monitoring, package feeds, identity endpoints, or shared services needed for investigation and recovery.

Blocking the subnet is fast to explain and often expensive to operate. If unrelated workloads share it, the containment boundary is larger than the incident boundary. A network action also does not remove the identity’s authority from other attached resources or alternate paths.

Coordinated containment

When evidence supports it, make a paired plan: reduce the identity authority that matters and restrict the network path from the compromised source. Keep the service dependency that healthy workloads require, or move those workloads to a known-good path if that has been rehearsed.

The plan needs an owner for each action, the exact target scope, a rollback or escalation condition, and a test that will show whether it worked. Don’t improvise a broad role deletion or shared firewall policy edit during an incident if a narrower, pre-approved option exists.

Separate the control-plane action from the outcome

Record the change request and the actual outcome. For identity, capture the principal, role/action, scope, and service operation under test. For networking, capture source, resolved destination, protocol/port, route or policy change, and connection result. Then test the expected legitimate operation from a known-good workload.

Azure Activity Log or resource configuration can help show that a control-plane change was submitted or recorded. That is not the same as evidence that every affected data-plane request now behaves as intended. Use service-specific documentation and a safe test to establish the effect; avoid promising a universal propagation interval.

Real-World Impact

Suppose a compromised image-processing VM reads uploaded content from Blob Storage using a managed identity. The same subnet hosts a clean service that writes audit records to the same account.

A subnet-wide deny may interrupt both applications and remove the logs responders wanted to keep. Removing a role assignment may stop the suspicious read but leave the compromised process able to reach other services through a shared identity or an intermediary. Doing both without checking dependencies can convert a security incident into an outage and still fail to close the path.

Before the incident, make a containment decision record:

Decision	Record before approval
Identity action	Principal, exact assignment/permission, scope, affected workloads
Network action	Source resource/subnet, destination, protocol/port, DNS dependency
Required service	What must remain reachable for healthy workloads and responders
Evidence	Baseline request, DNS answer, connection result, and known residual paths
Trigger	Confidence or condition that justifies the action
Recovery	Owner, rollback criteria, and retest required before reconnecting

During the incident, this does not remove the need for judgment. It makes the consequences visible before a responder has to choose under pressure.

Gotchas and Edge Cases

The safest containment action on a diagram can be the most damaging one in a running service. Shared identities and shared subnets are common because they simplify operations; incidents expose the cost of that coupling.

Existing tokens and sessions complicate timing

Submitting a role or identity change does not let you claim that every in-flight operation stopped at that instant. Token lifetime, service-side checks, caches, existing connections, and application retries can affect what responders observe. Check the service’s current documentation and verify behaviour in a controlled test; do not rely on a universal “revoked in N minutes” statement.

Shared identities expand the containment boundary

Removing an assignment from a user-assigned identity can affect every workload relying on it. Disabling or detaching it from one compute resource may not change what another attached resource can request. Inventory the identity’s assignments and attachments before using it as a single-workload kill switch.

Isolation can remove the evidence you need

The compromised workload may need to be cut off from external destinations while preserving a telemetry path to a trusted collection point. If the isolation design also removes DNS, management, or logging access, responders need a separate out-of-band method. Test this before relying on it.

The control plane may be part of the incident

If the attacker can change routes, NSGs, firewall policy, or role assignments, responders need confidence in the administrative identity and control path they use to contain the workload. A containment action performed through a compromised authority path can be undone or misrepresented.

Best Practices

Design at least three rehearsed options: identity reduction, source isolation, and coordinated containment. For each, name the scope, required permissions, expected service impact, telemetry retained, and recovery trigger. Favor reversible actions with a clear owner, but do not let reversibility become an excuse to defer a needed boundary change.

During response, establish the smallest useful path first: compromised source, identity, target operation, resolver, and route. Choose containment against that path, not against the easiest resource group or subnet label. If evidence is incomplete, say so and choose a bounded action that buys time without pretending the residual risk is gone.

Afterward, repeat the original request from the affected workload or a safe equivalent and test the healthy dependency from a known-good source. Document both results. A stopped attacker path and a working business function are separate acceptance criteria; you need both before declaring recovery complete.

🍺

Brewed Insight: Identity-only containment can leave a reachable service. Network-only containment can leave portable authority. Under pressure, know which edge you are cutting—and what still depends on it.

Learn More

Disable Peering Route Propagation in Azure (Preview)

Sun, 25 Oct 2026 00:00:00 +1100

You’ve pointed a summary route at the firewall, but traffic to a peered spoke still goes directly to the destination. Check the prefixes: a more-specific system peering route can beat your user-defined route (UDR).

For engineers operating hub-and-spoke inspection, disable peering route propagation (preview) offers a way to remove those competing peering routes instead of maintaining an override for every spoke. The useful outcome is less repeated route maintenance while keeping selected traffic on the inspection path.

There is one eligibility check to make before trying it: during preview, the firewall or network virtual appliance (NVA) next hop must be in the same VNet as the source workload NIC. A workload in the hub can meet that rule with a hub appliance. If your main problem is steering spoke-originated traffic through a firewall located only in the peered hub, this preview doesn’t currently solve it. That is a restriction of this preview feature, not a prohibition on ordinary UDR service chaining.

The Mental Model

Peering provides connectivity; routes determine which next hop a packet uses. This setting removes system-generated peering routes for supported workloads on the subnets associated with a route table. Your UDRs still have to supply the intended path.

Consider this illustrative hub-side workload, with the appliance in the same VNet and two peered spokes:

Route	Prefix	Next hop
System peering route	`10.20.0.0/16`	Peering to spoke A
System peering route	`10.21.0.0/16`	Peering to spoke B
User-defined summary	`10.20.0.0/15`	Hub appliance at `10.0.2.4`

Before suppression, traffic to 10.20.1.10 follows the /16 peering route, not the /15 UDR. Longest prefix match comes first; being user-defined doesn’t make a broader route win. After suppression, those peering routes are removed from consideration, allowing the summary UDR to select the appliance, assuming no other winning route exists.

That’s the change: remove the competing automatic routes, not change Azure’s route-precedence rules.

You can already override those system routes with matching-prefix UDRs: at an equal prefix length, a UDR takes precedence over a system peering route. This preview doesn’t introduce inspection as a new capability. It exchanges repeated per-peer route configuration for responsibility for every required peering path affected by suppression. Less route maintenance, more responsibility for route completeness is the trade-off.

Peering stays configured. Whether traffic still gets through depends on the replacement routes and the appliance path.

How It Really Works

The control lives on the route table as disablePeeringRoute. By default, None keeps system-generated peering routes; set it to All to suppress generated IPv4 and IPv6 peering routes for supported workloads on associated subnets.

The scope is easy to misread: it’s a route-table setting, not a switch on each peering connection. Every associated subnet inherits it for supported workloads. It doesn’t let you suppress just one chosen peer. Use separate tables when subnet routing policies differ.

Before configuration, register the Microsoft.Network/AllowDisablePeeringRoutes preview feature in the subscription that contains the route table. The setting is available through the Azure portal, CLI, and PowerShell; REST, ARM, and Bicep deployments need route-table API version 2025-07-01 or later.

For PowerShell, use Az.Network 8.1.0 or later. Sign in, select the subscription that owns the route table, and request preview registration once:

1
2
3
4
5
6
7


Connect-AzAccount -ErrorAction Stop
Set-AzContext -SubscriptionId "<subscription-id>" -ErrorAction Stop

Register-AzProviderFeature `
 -FeatureName AllowDisablePeeringRoutes `
 -ProviderNamespace Microsoft.Network `
 -ErrorAction Stop

Registration may take time. Run the following check again later if it isn’t ready; there’s no need to repeat the registration request. Refresh the network provider only after the feature reports Registered:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


$feature = Get-AzProviderFeature `
 -FeatureName AllowDisablePeeringRoutes `
 -ProviderNamespace Microsoft.Network `
 -ErrorAction Stop

if ($feature.RegistrationState -ne "Registered") {
 throw "Preview feature state is '$($feature.RegistrationState)'. Wait for Registered, then run this block again."
}

Register-AzResourceProvider -ProviderNamespace Microsoft.Network -ErrorAction Stop

The next example assumes the route table already exists and is associated with the source subnet. Choose a destination prefix that matches only traffic intended for inspection, and use an appliance private IP in the same VNet as the source workload NIC. It adds the UDR and enables peering-route suppression together:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


$resourceGroup = "<resource-group>"
$routeTableName = "<route-table-name>"
$routeName = "inspect-spoke-ranges"
$destinationPrefix = "<summarized-spoke-prefix>"
$appliancePrivateIp = "<nva-private-ip>"

$routeTable = Get-AzRouteTable `
 -ResourceGroupName $resourceGroup `
 -Name $routeTableName `
 -ErrorAction Stop

if ($routeTable.Routes.Name -contains $routeName) {
 throw "Route '$routeName' already exists. Review or update it explicitly before continuing."
}

$routeTable = Add-AzRouteConfig `
 -Name $routeName `
 -AddressPrefix $destinationPrefix `
 -NextHopType VirtualAppliance `
 -NextHopIpAddress $appliancePrivateIp `
 -RouteTable $routeTable `
 -ErrorAction Stop

$routeTable.DisablePeeringRoute = "All"
Set-AzRouteTable -RouteTable $routeTable -ErrorAction Stop

$updatedRouteTable = Get-AzRouteTable `
 -ResourceGroupName $resourceGroup `
 -Name $routeTableName `
 -ErrorAction Stop

$updatedRouteTable.DisablePeeringRoute
$updatedRouteTable.Routes |
 Where-Object Name -eq $routeName |
 Select-Object Name, AddressPrefix, NextHopType, NextHopIpAddress

This is a documented configuration example, not a report of an executed Azure test. It leaves existing routes and subnet associations in place; it doesn’t configure the appliance or its onward path. The final output confirms saved configuration, not effective forwarding. Review the existing routes and all associated subnets before applying it; pause other writers to the table while making the change.

To restore peering-route propagation, retrieve the table again, set DisablePeeringRoute to "None", and save it with Set-AzRouteTable. That alone isn’t a full rollback: the added UDR remains, and existing overrides still affect route selection. Preserve the original configuration and restore the routes your change plan requires.

Real-World Impact

The best fit is a growing hub-and-spoke network where eligible source subnets need the same inspection path to multiple spokes. Microsoft’s overview describes using suppression with a summary UDR to avoid maintaining an override for every peer. The day-to-day benefit is fewer route edits when another spoke joins that same routing policy.

A more manageable hub-and-spoke route table

Take a shared-service workload in the hub that contacts applications in the two spokes from the earlier example. Both destinations require inspection by the hub appliance. Without suppression, you might maintain /16 UDR overrides to beat the matching system peering routes. With suppression on the source subnet’s route table, the /15 summary can express that shared intent.

flowchart LR subgraph Hub VNet Source["Hub source subnet"] Appliance["Firewall or NVA"] end Spoke["Destination in peered spoke VNet"] Source -->|"UDR: spoke prefix"| Appliance Appliance -->|"Forwarded traffic over peering"| Spoke

The appliance must still forward traffic over peering to the destination. Don’t apply the source subnet’s suppression policy blindly to the appliance subnet: removing the appliance’s onward routes or sending it back to itself can break the path you’re trying to build.

For a stateful inspection design, the spoke’s response to the hub workload must also traverse the intended appliance path. The spoke may need a matching-prefix UDR for that return destination to override its direct peering route; changing the hub source table doesn’t configure this return route. The example shows the outbound route-selection change, not a complete bidirectional deployment.

When I would keep explicit routes

Suppose the next spoke needs a different appliance or must bypass this inspection path. Don’t widen the summary just to keep the table short. Keep its route explicit and review the remaining effective routes before enabling suppression for that source subnet.

My recommendation is to use this where the routing intent is genuinely repetitive and the address plan makes summarization safe. If every spoke needs an exception, a smaller table isn’t worth making the packet path harder to explain. This feature controls route propagation; it doesn’t centralize firewall management or replace destination-specific policy.

Gotchas and Edge Cases

The outage pattern is deceptively quiet: peering still shows connected, but an application times out because its old system route is gone and its replacement UDR is missing, wrong, or points to an appliance that cannot forward the flow. A healthy peering status does not validate the new path.

Suppression covers more than the summary

All suppresses generated IPv4 and IPv6 peering routes, not just the destinations covered by your new UDR. Inventory every peer and required destination first. One IPv4 summary won’t replace other IPv4 paths or any IPv6 paths you still need.

Route selection isn’t end-to-end inspection

Other routes can still win. This property doesn’t disable BGP route propagation, and it doesn’t remove existing UDRs. Check the effective route for each test destination rather than assuming suppression makes the summary authoritative.

Forwarding, firewall policy, NSGs, peering settings for forwarded traffic, and the return path are separate work. For a custom NVA, verify IP forwarding at the Azure NIC and appliance/OS layers. With a stateful firewall, asymmetric return traffic can break an otherwise plausible outbound design.

Preview workload and tooling exclusions

Azure BareMetal Infrastructure workloads aren’t covered: they retain standard longest-prefix-match behavior even when sharing a subnet with supported workloads. Terraform currently requires the AzAPI provider rather than AzureRM. Manage this preview setting on the route table, not through Azure Virtual Network Manager routing rule collections. Behavior and availability may change; check the current documentation before deployment.

Best Practices

Start with a dedicated canary source subnet and route table, not a table shared across production. Capture the original configuration and effective routes, then record a small test matrix: source NIC, destination IP, protocol/port, expected next hop, and expected application result. Include both inspected destinations and destinations outside the summary.

After applying the change, check three things:

Route selection: generated peering routes are suppressed for the supported source NIC, and the intended UDR selects the appliance for each inspected destination. Required paths outside the summary still have the correct route.
Actual traffic: bidirectional application tests succeed, and appliance telemetry shows the tested flows being processed. A successful connection alone doesn’t prove inspection; effective routes alone don’t prove packet delivery.
Maintenance reduction: compare the routes before and after. Retire redundant per-spoke overrides only after validating the replacement path; the PowerShell example deliberately doesn’t delete them.

If a required flow fails or takes an unexpected path, stop expansion and restore the captured route configuration, including the suppression setting. Agree on who performs that rollback before the change window. Repeat the checks when adding peers, changing address ranges, or introducing route exceptions.

🍺

Brewed Insight: Use this preview when many routes express the same inspection policy, not simply when the route table looks busy. Keep explicit routes where exceptions carry important intent. A shorter route table is only an improvement if the resulting packet path remains easy to explain.

Learn More

Can the Packet Reach the Identity’s Target?

Thu, 22 Oct 2026 00:00:00 +1100

The access review says the workload identity can read the storage account. The network diagram says the subnet has no route to it.

Which one is right?

Possibly both. Azure RBAC describes authority. Routes, DNS, firewalls, and network security groups shape reachability. Until you test the same source, destination, protocol, and operation, those documents are describing different slices of the system.

There is a familiar temptation here: treat a “reachable” result as an attack path, or an “unreachable” result as containment. Both conclusions get ahead of the evidence.

The Mental Model

A network test answers a narrow question: from this source, can a particular kind of connection be established to this destination at this time?

It does not answer whether the workload has permission to perform an operation once connected. Nor does a role assignment answer whether the packets can get there.

The testable claim is not “the identity can reach storage.” It is more like: “This VM’s application process resolves this hostname to this address, can establish TCP 443, and can read this test object using this principal.”

That sentence is longer because the architecture is more complicated than one green check.

Reachability is a property of a tested source, destination, protocol, and time—not an enduring property of an identity.

How It Really Works

Fix the test tuple before you run a probe

Record the source resource and actual runtime context, target FQDN or IP, expected resolver, protocol, destination port, and the business operation to test. For a workload identity path, capture the principal ID and the exact data or service action separately.

Avoid a vague scan of “the subnet.” A VM and a container on that VM may have different local firewall, proxy, DNS, or identity behaviour. A subnet-level effective rule view can explain policy, but it cannot prove what a process used.

For this article’s example, assume an Azure VM application connects to an Azure Storage Blob private endpoint using the service hostname and HTTPS on TCP 443. It is illustrative; no test was run against an Azure subscription. Record actual VM/Storage SKUs, region, endpoint subresource, resolver configuration, and client SDK/API version before applying the method to a tenant.

Use diagnostics for the question they can answer

Azure Network Watcher’s Connection troubleshoot supports TCP or ICMP tests from documented sources including virtual machines and virtual machine scale sets to destinations including VMs, FQDNs, URIs, and IP addresses. Its results can surface connectivity, DNS, route, NSG, and other supported configuration issues. The agentless experience is currently documented as preview; feature availability and behaviour need to be checked for the target environment.

That is useful. It is not an application transaction. A TCP success says a connection probe reached a listening port under the tested conditions. It does not prove the application resolved the same name, used the same proxy, negotiated TLS as expected, or presented the identity you reviewed. A TCP failure can come from the target not listening, a guest firewall, a missing route, policy, or a diagnostic prerequisite—not necessarily the security boundary you meant to test.

Pair the diagnostic with a test from the actual workload context. Resolve the application hostname there, record the address, then attempt a safe connection. Where practical, make a non-mutating application request with the intended identity. Keep results separate so one tool’s scope is not mistaken for another’s.

Inspect policy, but don’t confuse it with observation

Review the effective route, relevant NSG rules, Azure Firewall or network virtual appliance policy, peering/gateway path, and target-side restrictions that apply to the source/destination tuple. Which surfaces matter depends on the topology. A route table screenshot without the effective next hop is not enough; an NSG allow rule does not prove the target is listening.

For Network Watcher, confirm the service is enabled in the source VM’s region and check its current RBAC permission requirements. Built-in Network Contributor, Contributor, and Owner roles can include broad actions; custom roles may be more appropriate after verifying the exact diagnostic actions. Do not expand permissions merely to make a one-time test convenient.

The diagnostic data model, API version, supported sources, and permission set can change. This draft does not call a Network Watcher REST API, query a log schema, or assume a specific VM agent/extension. Name those versions and prerequisites when a real implementation uses them.

Test the service operation separately

If TCP connects, use the workload’s credential path to attempt one safe, read-only operation. For Blob Storage with Microsoft Entra ID, the data service evaluates authorization for the request; network reachability does not make the request permitted.

If the operation fails, record the service response and identity used. If it succeeds, record the object and operation. Avoid logging bearer tokens. The test should use non-sensitive data and a principal with only the access required for that test.

Real-World Impact

Suppose a workload has a role that appears to permit access to a sensitive data store, but the test from its current source cannot reach the target. That is worth investigating, but it is not a reason to leave the role untouched forever. The route may change; a proxy or alternate path may exist; another workload may share the identity.

Now reverse the result. The TCP probe succeeds, but the data operation is denied. Adding more network blocks might not reduce the specific authority exposure at all. The intended identity may not be in use, or the permission may be missing. An error message and principal ID are more useful than another blanket rule.

Use a reachability matrix that records both positive and negative cases:

Source	Destination	Protocol/port	Network result	Service operation	Interpretation
Workload process	Intended endpoint	TCP 443	Observed result	Safe read as target identity	Tests intended path
Same source	Known out-of-scope endpoint	TCP 443	Observed result	No data operation	Challenges network boundary
Same source	Intended service name	TCP 443	Observed result	Same read with wrong/unauthorized identity, if safe	Separates reachability from authority

Fill this in only from real tests. A blank or untested cell is not “denied.” Re-test after the change and retain the exact source, destination, protocol, timestamp, and identity so another engineer can reproduce the claim.

Gotchas and Edge Cases

The gap between control-plane configuration and a running process is where confident conclusions tend to get expensive. A clean route analysis can coexist with an application outage; a successful probe can coexist with a broken trust boundary.

Diagnostic sources may not match the process

Connection troubleshoot operates from supported Azure resource types and test modes. A test from a VM does not automatically represent every container, sidecar, proxy, or application library on that VM. Record what emitted the traffic and what did not.

A port test can pass for the wrong service

An address can accept TCP without being the intended service. Check DNS, destination ownership, TLS/service identity, and the application response. Do not treat “socket opened” as equivalent to “request reached the intended resource.”

Network policy is not the only failure domain

Guest firewall, process configuration, server listener state, DNS, service firewall, and platform diagnostic prerequisites may all affect results. Classify the failure before proposing a security change. If the diagnostic itself needs permissions or connectivity the workload lacks, that is not proof the workload’s normal path is blocked.

One successful test ages quickly

Routes, DNS, identities, and policy change independently. A reachability result is a snapshot, not a perpetual guarantee. Preserve its time and configuration context, and decide which changes invalidate it.

Best Practices

Before changing policy, write down what a passing test means. Specify the workload context, FQDN and expected destination, TCP/ICMP choice, port, identity, operation, and what result should be denied. Then use a diagnostic that answers the network question and a separate request that answers the authorization question.

When results disagree, don’t average them. If the network probe succeeds and the service denies access, inspect identity and operation. If the role appears valid and the request times out, inspect DNS, routing, enforcement, and target listener. If the answers change depending on source, name that boundary instead of calling the environment “reachable.”

Finally, preserve the failed and successful cases. They define where the boundary currently is. After a remediation, run the same tuple again and test an adjacent path that should remain available. That is how you tell containment from accidental outage.

🍺

Brewed Insight: The packet can reach a target the identity cannot use. The identity can be authorized for a target the workload cannot reach. Neither edge is the whole path; the review has to test where they meet.

Learn More

Private DNS Decides Where Trust Travels

Tue, 20 Oct 2026 00:00:00 +1100

The deployment looks tidy. There is a Private Endpoint, a private DNS zone, and a link to the workload’s VNet. Public network access is disabled.

Then someone asks how the application knows which IP to use.

That should not be a difficult question. In practice, the answer often stops at “the private zone is linked.” That is a resource configuration fact, not evidence of what the application resolved or where its request went.

Private connectivity changes the route. It does not make name resolution unimportant. For a workload that trusts a service hostname, DNS remains part of the decision about where that trust travels.

The Mental Model

A client normally asks for a service by name, not by drawing an arrow to a Private Endpoint NIC. DNS participates in turning that name into a destination. A private endpoint can be correctly provisioned while the client resolves through an unexpected resolver path, receives a stale answer, or reaches an address other than the one the design assumes.

There are three distinct claims here:

The intended DNS configuration exists.
The workload resolves the service name to the intended destination.
The request reaches and is authorized by the intended service.

Teams often establish the first claim, infer the second, and treat the third as solved because the answer was private. That is a lot of trust to place in one word.

A private DNS answer is evidence about name resolution. It is not a certificate of service identity or authorization.

How It Really Works

Follow the name the application actually uses

Begin with the service FQDN in the application’s configuration or request log. Do not start with an IP copied from a private endpoint resource. The question is how the real client resolves the name it actually requests.

For Azure Private Link, client applications can continue using the ordinary service hostname. DNS configuration can direct the query through the public CNAME chain and a private-link zone to a private address, depending on resolver context and zone configuration. Azure documents private DNS zones, VNet links, Azure Private Resolver, and forwarding patterns for private endpoint resolution.

The answer can differ across a VNet, a peered network, on-premises DNS, a container-specific resolver, and a developer workstation. A successful lookup from one vantage point is a result for that vantage point. It does not establish what a different resolver or cached client answer will do.

Configuration is not observed behaviour

Inspect the private endpoint’s DNS configuration and NIC addresses, the relevant private DNS zone and records, VNet links, and any custom resolver or forwarding rules. Then query from the workload’s actual execution context. Capture the question, resolver, full answer chain, TTL where available, timestamp, and address selected by the client.

That still leaves a second test: observe the destination used by the connection. A command-line DNS lookup is useful evidence, but the application may use a local cache, proxy, custom resolver library, or a long-lived connection. When practical, instrument the application’s request or test in the same process/container context. If that is not practical, state the gap rather than pretending a nearby VM is identical.

DNS does not replace the service checks

A DNS record does not grant access. Azure’s documentation is explicit that DNS resolution and access control are independent. The public CNAME chain may be resolvable even when a service denies the request, and a private address does not prove that the service accepted the intended identity or operation.

Test the remaining edges separately: connect to the resolved destination over the required protocol, then make a safe request with the workload’s intended identity. If the client reaches an unexpected address, investigate it. If it reaches the expected private IP but the service denies the operation, do not call DNS the failure merely because DNS was the most visible component.

The assumptions need to be visible

This article describes Azure Private Endpoint name resolution generally; a real implementation depends on the service’s supported private DNS zone name, endpoint subresource, resolver design, region, and service configuration. Record those for the environment under review. Do not mix records for multiple same-service private endpoints in one zone without verifying the supported design; Microsoft documents that some arrangements can remove an earlier A record and cause resolution failures.

There is no tested tenant result or specific Azure service instance in this example. If using Azure Private Resolver, identify the SKU/region and endpoint configuration. If relying on DNS logs or network telemetry, specify the source and schema. None is assumed here.

Real-World Impact

DNS failures are often treated as availability issues, and sometimes that is exactly what they are. A record disappears; the workload cannot resolve the service; the application fails. The security relevance is that the same dependency can influence which service the client attempts to reach, even when no route or application deployment changes.

Consider an application using the Storage Blob hostname account.blob.core.windows.net. In the intended private-link design, the resolver chain should lead the client to the private endpoint address for that account. One workload gets that answer. Another, using a different resolver path, gets a public address or an endpoint associated with another environment.

Those outcomes do not mean the second workload has accessed data. Public network access may be disabled; the service firewall, TLS validation, identity, and authorization still matter. But the intended private path was not proven. That distinction changes the incident response: investigate the resolver and client path before widening a firewall rule just to restore service.

This is why I would not use “resolves to RFC1918” as a success criterion. It says the answer is private address space. It does not say whose address it is, which service is listening there, or whether the intended service accepted the request.

Two remediation options can both look reasonable on a status board. Adding a broad network allow rule may make the application healthy again quickly. Correcting the zone link or forwarding path may take longer and require coordination with the DNS owner. If the failure is a wrong answer, the allow rule treats the symptom and expands the set of destinations the workload can reach. The right fix depends on observed DNS and connection evidence, not which team can close its ticket first.

Use a small resolution-to-destination record to support that decision:

Field	Evidence
Client	Workload, container/host context, and configured hostname
Resolver	Resolver address/service and forwarding path
Answer	Full CNAME/A/AAAA chain, response time, and TTL
Expected target	Private endpoint resource ID and NIC address from configuration
Observed destination	Address used by the actual connection, if observable
Service result	TLS/HTTP or service response and workload identity/operation
Boundary	Unchecked clients, regions, caches, or network paths

This makes a resolver change reviewable. It also gives incident responders something better than a screenshot of a zone link taken months earlier.

For a bounded validation, compare the exact hostname’s answer from the workload context against the private endpoint NIC address and then observe the address used by a safe client request. The expected result is a match for the intended endpoint and an authorized service response. If the test differs, record whether the divergence is in the resolver answer, client-used destination, or service authorization. That is a test criterion, not a tenant result reported here.

For platform and security leaders, this record also exposes an ownership decision. If the workload team cannot change or independently validate the resolver path, then DNS is a shared security dependency, not just a central IT service. The platform owner needs a change process, a defined incident escalation route, and a way to establish which clients may be affected. If those controls are not available, the architecture review should record the dependency as accepted risk rather than calling the application network isolated.

Gotchas and Edge Cases

DNS is a small protocol sitting in the middle of a large operational system. The edge cases are usually not exotic; they are the normal consequences of shared ownership, caching, and migration.

A private zone can change public-name behaviour

Linking a private zone that matches a public service namespace can affect queries for names without private records. Microsoft warns that resolution may fail unless public fallback or forwarding is configured appropriately. Avoid overriding a zone actively used for public endpoint resolution without understanding how missing records behave.

Multiple endpoints can collide

Microsoft’s Private Endpoint DNS guidance warns that associating a Private DNS zone for a service with multiple similar Private Endpoints can remove an earlier A record and break resolution. The exact supported design depends on service and DNS architecture. Don’t copy a “one zone per environment” pattern blindly; verify the current service guidance and test each consumer path.

Caches hide the change window

Resolvers and clients cache answers. A record update does not guarantee every process switches destinations at the same moment. Do not describe a DNS change as an immediate cutover unless you tested the relevant TTLs and client behaviour. Long-lived connections can continue using the destination selected earlier.

Central DNS is an authority decision

Centralizing DNS can simplify operations and support hybrid resolution. It also concentrates the ability to influence name answers. That may be the right trade-off, but it belongs in the threat model and change-approval path. “Platform-owned” does not mean “outside the workload’s trust boundary.”

If the central team cannot tell which workload depends on a zone, it cannot confidently scope an emergency change. If the application team cannot see what the resolver returned, it cannot confidently distinguish a DNS issue from a service outage. Shared ownership without shared evidence is not a control model; it is a hand-off gap.

Best Practices

Review DNS and network reachability as one path, but keep their evidence distinct. Record the resolver and actual answer from the workload, then identify the address the application connected to. Validate the service operation independently with the intended identity.

When you change a zone, link, forwarder, or resolver endpoint, test both the expected private service and a representative name without a private record. That second test can catch a private-zone configuration that quietly breaks public resolution. Use a safe non-production workload where possible.

Give each shared DNS dependency an owner and an incident path. Decide who can change it, how changes are reviewed, and what telemetry can show what answer clients received. DNS telemetry may not exist or may not capture every client; say what the evidence covers.

Agree the response lane before an incident: a wrong resolver answer routes first to DNS ownership; an expected private answer with a failed connection routes to network and endpoint diagnostics; a successful connection with a denied service operation routes to identity/service authorization. Reclassify if the evidence contradicts the first hypothesis. This avoids the familiar cycle where teams widen access while arguing about which dashboard is authoritative.

Most importantly, don’t call a private IP a trusted destination. Confirm it belongs to the intended endpoint, confirm the connection uses it, and confirm the service authorizes the intended operation. Each of those checks closes a different gap.

🍺

Brewed Insight: A Private Endpoint changes where packets can travel. DNS still helps choose where the workload sends them. If the review stops at “the answer was private,” it hasn’t yet shown that the right service received the request.

Learn More

When a Managed Identity Becomes a Pivot

Thu, 15 Oct 2026 00:00:00 +1100

“We moved it to managed identity, so there are no credentials for an attacker to steal.”

That is a good reason to remove a secret. It is not a reason to stop the review.

If a compromised process can ask for a token as its assigned identity, the useful question becomes what that identity can do next. Maybe the answer is one read against one storage account. Maybe the same identity is attached to three workloads and can reach a shared service with much broader authority. Those are not the same incident, even if both designs say “managed identity” on the diagram.

The identity does not become a pivot because the feature is weak. It becomes one when the workload’s legitimate authority and its reachable dependencies combine into a route to something else.

The Mental Model

A managed identity changes how a workload obtains credentials. It does not decide what the workload is authorized to do, which other resources can answer it, or whether network controls will let it connect.

Think of the pivot as the join between three edges:

Credential edge: can this compromised process request a token for the identity?
Authority edge: which operations can that principal perform, at what scope, and through which service?
Reachability edge: can the process contact the target or an intermediary that can act on the target?

The path matters only when its edges meet. A role assignment alone is not proof of network access. A reachable endpoint alone is not proof of data authorization. A token is not a map of every action the service will permit.

Secretless is a credential property. Contained is an outcome you still have to prove.

How It Really Works

First establish which identity is in play

Start in the workload’s execution context. Do not infer the principal from a deployment template or the identity settings on a resource that may not host the process. Record the actual principal ID and whether it is system-assigned or user-assigned.

That distinction affects the blast radius. A system-assigned managed identity is tied to the lifecycle of its Azure resource. A user-assigned identity is a separate resource and can be assigned to more than one Azure resource. Sharing one may simplify provisioning and role management. It also means compromise of any attached workload may expose the same identity authority, subject to the service’s identity-use behavior.

That isn’t a blanket argument against user-assigned identities. It is a design choice with a boundary attached. If a shared identity is used, reviewers should be able to name every workload that can use it and explain why those workloads belong in one compromise domain.

Follow the permission to the operation

“Reader” and “Contributor” often get discussed as though role names fully describe data access. They do not. For a Blob read, distinguish management-plane permissions on the Storage account from the data-plane authorization evaluated for the blob operation. A successful control-plane inventory is not proof that the application can read a particular object; a successful token request is not either.

Write down the operation the application needs. For example: read one known blob, list a container, or write an object. Then inspect the applicable role definition, assignment scope, inheritance, and conditions for the principal that actually makes the request. If the workload uses a broker or an intermediary service, follow that edge too. The workload may not have direct permission to the final data and still be able to invoke something that does.

Use a harmless test object and the same credential-selection behavior as the application. An engineer’s interactive sign-in can confirm that the engineer has access. It cannot establish what the managed identity can do.

Reachability is the other half

Once you know the target operation and principal, test where the workload can connect. Resolve the target hostname from the workload’s resolver context, record the address the client uses, and test the required protocol and port from the same source.

For a VM-based workload, Azure Network Watcher’s Connection troubleshoot can help diagnose supported TCP or ICMP connectivity to supported destinations. It can surface route, DNS, and network-security issues. It does not evaluate the Blob data permission or prove that application code uses the same identity and hostname. Treat it as one instrument in the investigation, not the answer.

If the data path includes a private endpoint, inspect its DNS resolution and network policy as part of the same path. A private address may reduce public exposure; it does not tell you how much data the identity is allowed to read after connection.

Real-World Impact

Imagine two applications attached to the same user-assigned identity. One processes uploaded images. The other performs a back-office reconciliation job. Both can obtain a token; both can reach the same Storage account.

If the identity has read access to every container because that was the easiest role to assign, a compromise in the lower-trust image processor can inherit authority intended for the reconciliation job. The pivot is not “managed identity was compromised” in isolation. It is the shared identity, broad operation scope, and reachable storage path taken together.

Now compare two fixes. Removing the identity from every workload may stop the immediate path, but also stop valid processing. Blocking all traffic to Storage can produce the same operational result. A narrower change might separate the identities, reduce data permissions to the required scope, and constrain the route. Which is right depends on whether the workloads genuinely share a trust boundary and what the application must do.

The test should make that choice visible. Record:

Evidence	Question it answers
Principal ID from the workload	Which identity actually requested access?
Role definition, scope, inheritance, conditions	What operation is potentially authorized?
Target operation and response	Did this request succeed as that identity?
Resolver and client-used address	Where did the process direct the request?
Source, destination, protocol, port	Could this workload establish the tested connection?
Other attached workloads	Who shares the identity boundary?

This is a review artifact, not a claim that every other path has been found. If there are multiple attached resources, network paths, or downstream services, show what was excluded and why.

Gotchas and Edge Cases

The term “pivot” can make ordinary service access sound more dramatic than the evidence supports. Keep the claim narrow: a pivot exists when a foothold can use authority or a reachable intermediary to move into a consequence-bearing operation. The word does not prove an attacker did so.

User-assigned identities can be useful when several resources need consistent authorization or a workload is recycled while its permissions remain stable. The same arrangement couples those resources’ compromise consequences. Count the attached workload resources and identify their owners before calling the identity “shared infrastructure.”

Scope is not just the assignment written on the resource

An assignment at a parent scope may apply lower down. Group membership and conditions can further affect effective access. Conversely, a role that sounds broad may not include the exact data action under review. Inspect role definitions and effective assignment paths; do not turn a role display name into a conclusion.

Token acquisition is not a permanent grant

Token handling and service authorization are distinct from network connectivity. Existing tokens, service-side authorization checks, caches, and established connections can make before/after behavior differ from the moment a control-plane change is submitted. Do not claim an exact revocation interval unless current service documentation and a measured test support it.

Intermediaries complicate the graph

A workload may reach a queue, function, or deployment service that then accesses the target with its own identity. The initial workload may have no direct Storage role, but that does not make the path irrelevant. Document the intermediary’s identity, authorization, and trust boundary instead of drawing an unexplained line from the application to the final data.

Best Practices

Begin with the operation, not the identity type. Ask what this workload must do, then prove the principal, authority, and destination used for that action. If multiple workloads share an identity, make the coupling an explicit architecture decision with named owners.

When a path is too broad, compare changes by what edge they remove. Separate identities when the workloads do not share a trust boundary. Narrow data permissions when the role exceeds the required operation. Restrict network paths when the source should not contact the target. Avoid using a network block to disguise excessive authority or an identity change to paper over an unintended route.

Finally, repeat the useful operation after the change and test one nearby operation that should remain denied. Capture exact request context and explain any propagation uncertainty. The goal is not to make every request fail. It is to preserve the needed dependency while removing the unnecessary pivot.

🍺

Brewed Insight: Managed identity answers how the workload proves who it is. The incident question is what that identity can do from that workload, over the paths the workload can actually reach.

Learn More

From Token to Packet: Trace an Azure Workload Attack Path

Tue, 13 Oct 2026 00:00:00 +1100

An application needs to read from Azure Storage. The team uses managed identity, puts a Private Endpoint in place, and restricts public access.

Those are sensible choices. They also make the design surprisingly easy to stop questioning.

The identity review checks the permissions. The network review checks private connectivity. Each team can approve its part without answering what happens if the application itself becomes hostile. After all, reading data is what this workload was built to do.

The uncomfortable question isn’t whether those controls exist. It’s whether a compromised process can use them to do more than the business dependency requires.

That is where the review needs to follow a request, rather than collect another approval.

The Mental Model

The common assumption is that a narrowly permitted identity and a private network path add up to a contained workload.

They might. But the identity and network diagrams don’t establish that on their own. The application may select a different identity, resolve a different destination, or have access to more data than its owners intended.

Consider an application on an Azure VM reading a blob through a Blob private endpoint. This is an illustrative design, not a tenant observation. Its authority and its packet path meet at the service:

What matters in this diagram is the join. The permission must belong to the principal making the request, and the route must lead to the destination the client actually uses. Otherwise, the review is describing two different things and calling them one boundary.

A permission review and a connectivity test only describe an attack path if they describe the same workload request.

Private connectivity can narrow exposure without narrowing the data available to an authorized process. Managed identity can remove stored credentials without making that process trustworthy. Neither control has failed when a compromised application uses its legitimate access. The architecture may simply have allowed too much.

How It Really Works

“Can access storage” is a poor starting point because it hides the operation. Reading a blob, listing a container, and changing account configuration are different decisions. For this example, use a read-only request against known, non-sensitive test data.

The identity in the diagram might not be the identity in the request

A role assignment is easy to inspect. Establishing that it belongs to the identity the application actually uses takes more care. A user-assigned identity may serve several workloads; a system-assigned identity is tied to its resource. Sharing an identity can make deployment easier while making the incident boundary larger than the application boundary.

For Blob access using Microsoft Entra ID, token acquisition and data authorization are separate steps. The Blob service still has to accept the operation. Inspect the applicable data permissions, inherited assignments, and conditions, then make the request using the workload’s credential selection.

This is why an engineer’s successful az login test can be so unhelpful in a workload review. It proves something about the engineer’s access. The application could still be using another principal entirely.

Follow the name before following the route

The application normally keeps using the service hostname. Private DNS configuration should lead it to the intended private endpoint address. Whether it does depends on the resolver, zone links, forwarding, and any local overrides.

A lookup from a management VM elsewhere in the network can look reassuring and still tell you little about the application’s resolver path. Use the workload’s runtime context and capture the address the client uses, not just the answer from a separate lookup. Caches and proxies are part of the explanation, not troubleshooting details to discard once a private IP appears.

Now test TCP 443 from that same source. Network Watcher’s Connection troubleshoot can help investigate supported sources and destinations, including route, DNS, and network-security issues. It cannot tell you whether the Blob service accepts this identity’s read request. You still need that request.

Be precise about which Azure behaviour you rely on

Microsoft documents the managed identity, Blob authorization, private DNS, and Network Watcher mechanisms linked below. Those documents support the method; they are not evidence that your tenant behaves as intended.

For this example, the target is an Azure Resource Manager-deployed Storage account’s Blob service over HTTPS/TCP 443. A real test record needs the Azure region, VM and Storage SKUs, runtime/SDK versions, and resolver configuration. There is no deployed lab or measured result behind this example.

When inspecting conditional RBAC assignments through the Role Assignments REST API, use 2022-04-01 or a later supported version and examine relevant parent scopes and role definitions. For Network Watcher, check regional enablement, supported sources, diagnostic prerequisites, and required RBAC actions. Its documented agentless experience is preview. Don’t build an incident dependency around an assumed feature.

The workload’s Blob read permission is separate from the investigator’s assignment-inspection and diagnostic permissions. No Storage or Network Watcher REST request or log query is supplied here; pin those API versions and telemetry schemas when an implementation depends on them.

Real-World Impact

This changes what a design review is prepared to accept. A working application is evidence that its dependency works; it is not evidence that the dependency is appropriately bounded.

Suppose the test blob can be read, but the connection goes to a public address when the design calls for private access. The request succeeded. The intended path did not. Calling that a pass would hide a DNS or client-routing assumption that needs investigation.

The opposite result is just as easy to misread. Private connectivity works, but Blob access is denied. That isn’t proof of containment until you know why. The test could be using the wrong identity, asking for the wrong operation, or hitting a permission that hasn’t propagated.

Keep the explanation attached to the path. A small record is more useful here than a control inventory:

Field	What to record
Claim	This process, using this principal, can read this test blob through this private endpoint
Source and identity	Runtime/compute resource, principal ID, credential selection
Destination	Service hostname, resolver used, DNS answer, client-used address, TCP port
Authority	Role definition, assignment scope, conditions, requested data operation
Result	Timestamp, request outcome/error, network diagnostic result, evidence reference
After a change	Exact change, comparable retest, remaining paths and unanswered questions

This is a template, not a populated evidence pack. Use it in an authorized environment with non-sensitive test data; do not store bearer tokens.

An unexpected destination disproves the claimed private path. A denied read means the operation didn’t succeed in that test; it does not, without an explanation, establish a durable security boundary.

For the before/after test, choose a second, non-sensitive blob that this workload should not read. The required read should succeed and the prohibited read should fail for an understood authorization reason. Repeat both after a scoped permission change. If both fail, you’ve broken the dependency; you haven’t demonstrated useful containment. If both succeed, the proposed boundary hasn’t held. These are expected outcomes for a test design, not reported measurements.

“Access stopped” is a poor success criterion when the application stopped with it. The defensible outcome is more specific: the required dependency still works, and the unnecessary access tested no longer does.

Gotchas and Edge Cases

A path test can give a very convincing answer to the wrong question. Source context, timing, and operational dependencies are where that usually becomes visible.

A test from the host can miss the application

Containers, proxies, and different resolver settings can make the application behave differently from a shell on its VM. Test inside the process’s actual context where practical. Where that isn’t possible, document the difference instead of quietly treating the host as equivalent.

Removing a permission is not the same as ending access immediately

After an authorization change, repeat the operation and account for service-specific propagation and caching. Existing connections and fresh connections may behave differently too. A diagram showing an edge removed is a change record; the retest is what tells you whether the intended outcome has taken effect.

Tighter boundaries have operating costs

A private path introduces DNS and connectivity dependencies. Narrower roles need maintenance when the application changes. Neither is a reason to abandon them, but both need owners.

There is also a temptation to grant broad investigator permissions so the diagnostics run without friction. That creates another powerful identity to govern. Prefer the permissions the diagnostic actually needs, with a pre-agreed escalation path for incidents, rather than solving investigation inconvenience with unrelated write authority.

Best Practices

Start with a dependency whose compromise would matter. Work through its authority and connectivity together, using non-sensitive test data in an authorized, preferably disposable environment. Name the test owner and cleanup requirements, including any temporary permissions.

Bring the identity and network evidence into the same review. Where the results disagree, leave the question open until someone can explain it. A failed connection with broad permissions still deserves an authority review; a reachable service with a denied read still deserves scrutiny of the other permitted operations.

The review should produce something the next change can invalidate. If an identity assignment, resolver path, route, or firewall rule changes, revisit the affected dependency. A “verified” diagram that survives every infrastructure change without a retest isn’t assurance. It’s an old diagram.

There is no complete-estate assurance claim in one VM-to-Blob test. What you have is a defensible answer for one path, plus a method to investigate the next.

🍺

Brewed Insight: Before signing off a workload boundary, ask for the request that crosses it. Who made it, where did it go, what did it do, and what stopped it after the change? Separate approvals aren’t a substitute for that answer.

Learn More

Operating Azure Security Telemetry as a Product

Thu, 08 Oct 2026 00:00:00 +1100

The final challenge in Azure security telemetry is not technical collection. It is operations. Many organizations can send logs to a workspace. Fewer can explain which signals are critical, who owns them, how quality is measured, and how detection content changes when the platform changes.

Security telemetry should be operated like a product with customers, quality measures, lifecycle management, and clear ownership.

This final post in the series pulls the previous themes into an operating model for Azure security telemetry.

The Mental Model

Treat telemetry as a product whose customers are incident responders, detection engineers, platform teams, auditors, application owners, and risk leaders. Each customer needs different outcomes. Analysts need fast investigation paths. Detection engineers need reliable schemas and test data. Platform teams need coverage standards and automation. Leaders need assurance and trend reporting.

The product has features: control-plane visibility, diagnostic coverage, normalized Sentinel content, Defender XDR hunting, Defender for Cloud export, dashboards, alert rules, and retention. It also has quality attributes: completeness, freshness, accuracy, accessibility, cost efficiency, and resilience against tampering.

This model changes the governance conversation. Instead of asking whether logs are enabled, ask whether the telemetry product meets its service expectations. Can the team reconstruct privileged changes? Can they investigate storage access? Can they correlate endpoint and identity behavior with Azure operations? Can they identify missing diagnostic settings? Can they prove which subscriptions are covered?

The operating model should also recognize that telemetry changes continuously. Azure services add categories, schemas evolve, teams create new subscriptions, detection rules age, and business priorities shift. A one-time logging project will decay. A product model expects lifecycle management.

How It Really Works

An Azure security telemetry operating model usually has four layers: platform collection, security analytics, response workflow, and governance feedback. Platform collection ensures logs are routed and retained. Security analytics turns data into detections and hunts. Response workflow defines how signals are triaged and remediated. Governance feedback measures coverage, cost, exceptions, and outcomes.

flowchart TD A[Telemetry Product Backlog] --> B[Collection Standards] B --> C[Workspace and Routing Architecture] C --> D[Sentinel Content and Defender Hunts] D --> E[Incidents, Tickets, and Response] E --> F[Metrics and Lessons Learned] F --> A

Ownership should be explicit. A cloud platform team may own policy-based diagnostic settings and workspace architecture. A security operations team may own Sentinel analytics and incident response. A detection engineering function may own rule lifecycle and testing. A governance or risk function may own reporting and exceptions. Application teams may own resource-specific remediation.

Quality control needs measurable checks. Examples include percentage of production subscriptions with Activity Log routing, percentage of high-risk resources with required diagnostic settings, number of analytic rules without owners, median age of Defender for Cloud recommendations, failed parser tests, ingestion cost by source, and incident timelines with missing evidence.

Change management is part of the design. When a new Azure service is introduced, the telemetry product backlog should ask which logs are required, which detections are relevant, which Defender controls apply, and how the service will appear in risk reporting. That makes telemetry part of platform adoption rather than an afterthought.

Real-World Impact

Operating telemetry as a product improves incident response because the response team knows what evidence should exist. When a major incident happens, they are not discovering the logging estate for the first time. They can use documented investigation paths, known workspaces, known tables, and known escalation owners.

It also improves platform engineering. Diagnostic settings, policy assignments, Sentinel connectors, and Defender exports become part of the landing zone and workload onboarding process. Teams can create resources faster because the security expectations are already encoded in reusable patterns.

For security leadership, the product model produces better metrics. Instead of reporting raw log volume, leaders can report coverage against critical scenarios, detection health, remediation age, and known gaps. That supports risk-based investment decisions. If a high-risk service lacks telemetry, the decision is visible and can be prioritized.

For auditors and assurance teams, the model creates traceability. Standards define what should be collected. Policy and queries show whether it is collected. Workflows show how findings are handled. Exceptions show who accepted risk and until when. That is much stronger than a screenshot of a workspace.

The product model also helps control cost. Cost is no longer a surprise created by indiscriminate ingestion. It becomes a managed product attribute. Teams can decide where to spend telemetry budget because each source is tied to a detection, investigation, compliance, or operational outcome.

Gotchas and Edge Cases

The first gotcha is treating the workspace as the product. A Log Analytics workspace or Sentinel instance is infrastructure. The product is the end-to-end capability to collect, interpret, respond, and improve. If ownership stops at the workspace boundary, the operating model is incomplete.

The second gotcha is weak rule ownership. Analytic rules without owners become stale. They generate false positives, miss schema changes, or remain enabled long after the underlying risk changed. Every rule should have a purpose, owner, severity rationale, and review cadence.

The third gotcha is exception sprawl. Logging exceptions, policy exemptions, disabled connectors, and suppressed recommendations may be reasonable individually. Collectively, they can hollow out the telemetry model. Exceptions need expiry dates and periodic review.

Another edge case is multi-workspace design. Some organizations split workspaces by region, tenant, business unit, or data boundary. That can be valid, but it complicates detection engineering and investigation. The operating model must explain how cross-workspace incidents are handled.

Finally, beware of metrics that reward volume. Ingestion volume, alert count, or number of connectors can all go up while security value goes down. Measure coverage, fidelity, response usefulness, and reduction of unknowns instead.

Best Practices

Create a telemetry product charter. Define the purpose, customers, scope, critical scenarios, data sources, ownership model, and success measures. Keep it short enough that teams will read it, but precise enough that it can guide decisions.

Maintain a signal catalog. For each major source, document why it is collected, where it is routed, how long it is retained, which detections or investigations depend on it, and who owns it. Review the catalog after major incidents and platform changes.

Run coverage tests. Do not wait for incidents to discover missing logs. Periodically simulate or query for expected events such as role assignments, diagnostic setting changes, key vault access, network rule updates, Defender for Cloud exports, and Sentinel incident creation.

Manage detections through a lifecycle. New rules should have a hypothesis, data dependency, test method, severity rationale, and response owner. Existing rules should be reviewed for false positives, stale assumptions, schema changes, and business relevance.

Close the loop with lessons learned. Every incident and major investigation should ask whether telemetry helped, slowed the team down, or was missing. Feed those lessons into the backlog. That is how the telemetry product improves over time.

Hailes Telemetry Utility Score

The scorecard I use for this is the Hailes Telemetry Utility Score. It is Chris Hailes’s practitioner framework, not a Microsoft standard. The point is to measure whether telemetry reduces uncertainty during an investigation, not whether the environment has produced the largest possible log volume.

Score each dimension from 0 to 5:

Dimension	What it measures
Completeness	Critical subscriptions, identities, resources, Defender findings, and response paths are represented.
Freshness	Data arrives fast enough for the decision it supports.
Accuracy	Fields are mapped correctly, parsers are tested, and source semantics are understood.
Accessibility and coverage	The right teams can query the right workspaces, tables, and portals without over-privilege.
Cost efficiency	Ingestion and retention spend are tied to detection, investigation, assurance, or response value.
Tamper resilience	Diagnostic settings, workspaces, exports, retention, and administrative paths are protected and monitored.

1

Hailes Telemetry Utility Score = ((completeness + freshness + accuracy + accessibility + costEfficiency + tamperResilience) / 30) * 100

Use 85-100 as operationally dependable, 70-84 as useful but still fragile, 50-69 as partial visibility, and below 50 as not defensible for the assessed scenario. For example, a privileged-access scenario scored 4 for completeness, 4 for freshness, 3 for accuracy, 4 for accessibility, 3 for cost efficiency, and 2 for tamper resilience lands at 66.7. That tells me the next investment should be tamper protection and parser validation, not another dashboard.

🍺

Brewed Insight: The highest-value Azure security telemetry programs I’ve seen are never the ones with the most data. They’re the ones where every critical signal has a name attached to it, a reason it exists, and someone who’d actually notice if it stopped firing.

Learn More

Turning Defender for Cloud Findings into Operational Signals

Tue, 06 Oct 2026 00:00:00 +1100

Microsoft Defender for Cloud produces security alerts and recommendations that can be extremely valuable, but only if they flow into the operating model. A recommendation that stays on a portal page is posture information. A recommendation that is exported, assigned, trended, and correlated becomes operational telemetry.

Defender for Cloud findings become security telemetry when they are routed into decisions, not when they are merely visible.

This post focuses on continuous export and the design choices that turn posture and threat findings into signals that security and platform teams can act on.

The Mental Model

Defender for Cloud sits at the intersection of posture management and workload protection. It identifies recommendations, regulatory alignment issues, attack paths, and security alerts across supported Azure and hybrid resources. Those findings are not the same as raw resource logs. They are interpreted signals: Microsoft has already applied assessment, analytics, or threat intelligence to produce them.

The mental model is findings as operational inputs. Some findings should drive engineering backlog. Some should create incident response activity. Some should inform risk dashboards. Some should be suppressed or accepted with an owner and expiry. If all findings are treated the same, teams either drown in work or ignore the portal.

Continuous export matters because it moves Defender for Cloud data from a product experience into an enterprise workflow. Microsoft documentation states that Defender for Cloud alerts and recommendations can be exported to Log Analytics, Event Hubs, another SIEM, SOAR, or other solutions. Data can stream as it is generated, or snapshots can be sent on a schedule.

That routing choice is strategic. Log Analytics supports querying, workbooks, Sentinel integration, and operational analysis. Event Hubs supports streaming to central platforms or external SIEM tools. The right destination depends on who owns the response and what they need to do with the finding.

How It Really Works

Continuous export is configured in Defender for Cloud environment settings. You choose the subscription, select continuous export, choose target type such as Log Analytics workspace or Event Hubs, select data types, apply filters, and define export frequency. Export can include security alerts, recommendations, and in some cases associated findings.

flowchart LR A[Defender for Cloud] --> B[Alerts] A --> C[Recommendations] B --> D[Continuous Export] C --> D D --> E[Log Analytics] D --> F[Event Hubs] E --> G[Sentinel and Workbooks] F --> H[SIEM SOAR or Data Platform]

Export frequency needs attention. Streaming sends updates as resource health state changes. Snapshots send the current state on a schedule, such as weekly per subscription for selected data types. Snapshot data can include a field that identifies it as a snapshot. That distinction matters when analysts build trend queries or detections, because state snapshots are not the same as new events.

Filtering is also important. Defender for Cloud can generate many recommendations. Exporting every low-priority posture recommendation into an incident workflow can create noise. Exporting only high-severity alerts may miss useful risk context. The goal is to route the right level of signal to the right workflow.

At scale, Azure Policy can help configure continuous export. This matters in multi-subscription environments where manual configuration will drift. Centralized export also requires permissions to the target workspace or event hub and appropriate Defender for Cloud permissions.

I route every exported finding into one of three lanes, and I reclassify the moment new evidence changes the picture. Lane 1 (path-break) is for an alert or recommendation that reveals a live route to identity, secrets, or control-plane operations - it goes straight to incident response, bypassing the standard posture backlog. Lane 2 (systemic control) is for a recommendation that recurs across many resources, such as the same missing control appearing on dozens of storage accounts - this gets a policy-level fix, not one ticket per resource. Lane 3 (architecture debt) is for low-severity, isolated findings that are real but not urgent - these get tracked with an owner and a review date, not chased immediately. A finding moves lanes the moment its blast radius or exploitability changes; the lane, not the original severity label, decides who acts and how fast.

Real-World Impact

The first impact is posture accountability. If Defender for Cloud recommendations are exported to Log Analytics, platform teams can trend unhealthy resources, recurring recommendations, aging findings, and remediation progress. That enables a monthly or weekly operating rhythm instead of ad hoc portal review.

The second impact is incident enrichment. A Defender for Cloud alert is more useful when correlated with Activity Log, resource logs, identity events, and Sentinel incidents. For example, an alert on suspicious workload behavior can be enriched with recent administrative changes, public exposure changes, or identity activity. That shortens triage and helps teams decide severity.

The third impact is engineering prioritization. Not every recommendation should become a ticket immediately. Exported findings allow teams to rank by severity, resource criticality, exposure, business owner, and age. That helps security teams avoid the “giant spreadsheet of shame” pattern and move toward risk-based remediation.

Continuous export also supports audit and assurance. Leaders can show that cloud security posture is not only reviewed in a portal, but routed into measurable workflows. They can demonstrate which teams own remediation, which recommendations are accepted risks, and which alerts triggered response.

For hybrid environments, Defender for Cloud exports can also help bring non-Azure workloads into the same conversation, depending on coverage and onboarding. That matters for enterprises where Azure resources, Arc-enabled servers, containers, and other platforms all contribute to risk.

This is the trade-off I put in front of a remediation-prioritization debate directly: closing 100 low-severity posture recommendations across dev subscriptions is easy to report and looks productive, but it’s worth less than fixing the one exported alert showing a production key vault with a live path to a compromised identity. Given a choice between those two bodies of work in the same sprint, I take the one alert every time. If your remediation backlog can’t tell those two situations apart, it’s counting tickets, not reducing exposure.

Gotchas and Edge Cases

The first gotcha is confusing recommendations with alerts. Recommendations often describe posture gaps or configuration improvements. Alerts usually describe suspected threat activity. They deserve different routing, severity, and ownership. Sending both into the same queue without classification creates confusion.

The second gotcha is snapshot interpretation. A weekly snapshot is useful for posture reporting, but it should not be treated like a new incident every time it appears. Queries and workflows need to account for snapshot markers and state changes.

Permissions and target configuration can also fail quietly from an operating perspective. Export requires write permissions to the target and appropriate Defender for Cloud roles. If central teams configure exports across subscriptions, they need a clear permission model.

Record size and data limits matter. Microsoft notes that Log Analytics supports records up to a specific size limit, and oversized records can trigger data limit messages. This is not usually the first design concern, but it matters for large findings or detailed vulnerability data.

Finally, exporting data does not mean someone owns it. A workspace full of Defender for Cloud findings is not an operating model. Define which team responds to alerts, which team remediates posture recommendations, how exceptions are approved, and how stale findings are escalated.

The anti-pattern I push back on every time I see it is a remediation KPI built around ticket-closure count for exported findings. That number rewards clearing easy, low-consequence recommendations while the one exported alert tied to a live production path sits in the queue because it’s harder to fix. The metric that should drive the report is the age and exposure of unresolved Lane 1 findings, not the total number of tickets closed.

Best Practices

Separate alert workflows from recommendation workflows. Route high-confidence threat alerts toward incident response. Route posture recommendations toward engineering remediation, backlog management, or governance review. Use common reporting, but do not force the same process.

Use continuous export to centralize visibility across subscriptions. Prefer policy-based configuration where scale requires it. Review export coverage regularly so newly created subscriptions do not fall outside the telemetry model.

Design filters deliberately. Export enough context to support investigation and risk reporting, but avoid flooding the workspace with low-value noise. Revisit filters as the organization matures.

Correlate Defender for Cloud findings with other telemetry. A recommendation becomes more useful when combined with exposure, asset criticality, ownership, and recent changes. An alert becomes more useful when combined with identity, endpoint, and resource behavior.

Measure remediation age and recurrence. The most important posture questions are often not “how many findings exist?” but “which findings are old, recurring, high-impact, externally exposed, or lacking an owner?”

Practical continuous export pattern

For broad rollout, start with Microsoft’s built-in Azure Policy definitions for Defender for Cloud continuous export: ffb6f416-7bd2-4488-8828-56585fef2be9 for Log Analytics and cdfcce10-4578-4ecd-9703-530938e4abcb for Event Hubs. Where you manage the automation directly, this Bicep pattern uses the Microsoft.Security/automations@2019-01-01-preview resource to export selected findings to a workspace.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


param location string = resourceGroup().location
param workspaceResourceId string

resource continuousExport 'Microsoft.Security/automations@2019-01-01-preview' = {
 name: 'export-defender-for-cloud-to-law'
 location: location
 properties: {
 isEnabled: true
 scopes: [
 {
 description: 'Subscription scope'
 scopePath: subscription().id
 }
 ]
 sources: [
 {
 eventSource: 'Alerts'
 }
 {
 eventSource: 'Assessments'
 }
 {
 eventSource: 'AssessmentsSnapshot'
 }
 {
 eventSource: 'SecureScores'
 }
 {
 eventSource: 'AttackPaths'
 }
 ]
 actions: [
 {
 actionType: 'Workspace'
 workspaceResourceId: workspaceResourceId
 }
 ]
 }
}

Once export is flowing, start with separate queries for recommendations and alerts so posture backlog work does not get confused with incident response.

1
2
3
4


SecurityRecommendation
| where TimeGenerated >= ago(30d)
| summarize LatestTime = max(TimeGenerated), States = make_set(RecommendationState, 5), Severities = make_set(RecommendationSeverity, 5), SnapshotRecords = countif(IsSnapshot == true) by AssessedResourceId, RecommendationDisplayName, RecommendationId
| order by LatestTime desc

1
2
3
4
5


SecurityAlert
| where TimeGenerated >= ago(14d)
| where ProductName has "Defender for Cloud" or ProviderName has "Security Center"
| project TimeGenerated, AlertName, AlertSeverity, Status, ProductName, ProviderName, ResourceId, CompromisedEntity, Tactics, Techniques, SystemAlertId, AlertLink
| order by TimeGenerated desc

Prerequisites are not optional: Defender for Cloud must be enabled, the target workspace needs the required solution path, and the configuring identity needs the documented Defender for Cloud and target write permissions. SecurityAlert and SecurityRecommendation are the documented Log Analytics tables for exported alerts and recommendations, but field population still depends on the finding type and export path.

🍺

Brewed Insight: Continuous export isn’t just an integration feature to enable and forget. It’s the mechanism that turns cloud posture into an accountable operational signal - one with an owner and a queue, not a recommendation sitting unread on a portal page.

Learn More

Using Defender XDR Advanced Hunting as a Cross-Domain Lens

Thu, 01 Oct 2026 00:00:00 +1000

Azure security telemetry is not complete if it only describes Azure resources. Real attacks move through identities, devices, email, cloud apps, network paths, and management planes. Microsoft Defender XDR advanced hunting gives security teams a cross-domain lens for that movement.

Azure telemetry explains the cloud estate; Defender XDR helps explain the actors and devices moving through it.

This post looks at advanced hunting as part of the security telemetry architecture, not just as an analyst search box.

The Mental Model

Advanced hunting is a query-based threat hunting capability in Microsoft Defender that lets you explore raw telemetry across security domains. Microsoft documentation describes it as a way to inspect events in your network and locate threat indicators and entities. It can query data from Microsoft Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, Defender for Identity, and Microsoft Sentinel when connected through the unified portal.

The mental model is entity-centered investigation. Azure logs can tell you that a role assignment changed, a resource was accessed, or a policy was modified. Defender XDR can help answer what the user, device, mailbox, app, or identity was doing around the same time. That context is what turns a suspicious event into a credible incident story.

For example, a risky Azure administrative operation is more meaningful if the same user had unusual sign-in behavior, endpoint alerts, suspicious cloud app activity, or email compromise indicators. Conversely, an endpoint alert is more concerning if the same identity later changes Azure access controls.

Advanced hunting is also useful because it speaks KQL. That lowers the mental switching cost for teams already using Azure Monitor Logs and Microsoft Sentinel. The schemas are different, but the investigation habit is similar: establish time, entity, action, result, and correlation.

The opinionated design choice is this: Defender XDR should not be used as a dumping ground for every Azure question. It should be used when the Azure event needs actor, device, mailbox, SaaS, or identity context to make the decision defensible. If the question can be answered completely in Azure Monitor or Sentinel, keep it there. If the question depends on what the user or device did before and after the Azure action, advanced hunting becomes the stronger lens.

How It Really Works

Advanced hunting has guided and advanced modes. Guided mode helps users who are less familiar with KQL. Advanced mode supports writing KQL directly. The same hunting queries can also support custom detection rules, which run automatically to check for suspected breach activity, misconfiguration, or other findings.

flowchart TD A[Defender for Endpoint] --> E[Advanced Hunting] B[Defender for Identity] --> E C[Defender for Office 365] --> E D[Defender for Cloud Apps] --> E F[Microsoft Sentinel Tables] --> E E --> G[Hunts] E --> H[Custom Detections] E --> I[Incident Investigation]

Data freshness matters. Microsoft separates advanced hunting data into event or activity data and entity data. Event data, such as alerts and security events, is generally available quickly after sensors transmit it. Entity data, such as user and device information, is updated on a different cadence. That distinction matters when a query appears to miss context during a live investigation.

There are also quotas and time windows. Defender advanced hunting can query up to 30 days of Defender data unless data is streamed through Microsoft Sentinel for longer retention. Query results, execution time, and resource usage have limits. These boundaries should influence how teams design operational hunts and custom detections.

Permissions are part of the architecture. Access to advanced hunting can depend on Microsoft Defender XDR unified RBAC, Defender portal permissions, Exchange Online roles, Microsoft Entra roles, and endpoint RBAC settings. A hunt program that works only for global administrators is not a sustainable operating model.

Time zone behavior is another operational detail. Advanced hunting uses UTC for queries, while results can be displayed according to portal time zone settings. Incident processes should be explicit about time normalization to avoid timeline confusion.

Real-World Impact

Advanced hunting improves Azure investigations by adding user and device context. Suppose an identity creates a privileged role assignment in Azure. Activity Log can show the management operation. Entra sign-in logs can add authentication context. Defender XDR can add endpoint, email, app, and identity behavior around the same period. Together, they help determine whether this was expected administration, compromised identity activity, or part of a broader attack path.

Another example is suspicious resource access from a managed device. Azure resource logs may show access to storage, key vault, or application endpoints. Defender for Endpoint telemetry may show process execution, network connections, script activity, or device risk. The combination helps analysts answer whether the resource event was business activity or a compromised workstation reaching into cloud assets.

Custom detections are where hunting becomes operational. A useful hunt can become a detection rule when it describes a repeatable risk pattern. That transition should be governed. Not every clever query should become an alert. The query needs a response owner, severity logic, tuning strategy, and evidence that the signal is worth interrupting someone.

For leadership, advanced hunting supports a more realistic security narrative. It acknowledges that Azure security is tied to identities and endpoints, not isolated resource controls. That is important for risk reporting because many cloud incidents begin outside the cloud control plane.

This is where prioritization becomes concrete. Closing one hundred low-risk findings may look productive, but it can be less valuable than one hunt that proves a compromised endpoint reached a privileged cloud control path. The better success measure is not volume of queries run or alerts created. The better measure is whether a hunt reduces uncertainty about a plausible attack path: identity compromise to endpoint activity, endpoint activity to cloud access, and cloud access to control-plane change.

For a senior security audience, that distinction matters. Advanced hunting should help leaders choose between competing response options. If two issues are both noisy, prefer the one that breaks a trust edge or removes attacker mobility. If two detections both appear severe, prefer the one with clearer entity linkage and a defined response owner. If a hunt cannot change a triage, containment, or remediation decision, it is probably research, not an operational signal.

Gotchas and Edge Cases

The first gotcha is retention. If teams assume advanced hunting is a long-term archive, they may be surprised by the default 30-day Defender data query window. Longer-term requirements may need Microsoft Sentinel, streaming APIs, or another retention architecture.

The second gotcha is query cost and limits. Advanced hunting has limits around result size, timeout, and CPU resources. Broad queries over large data sets can be blocked or return partial results. Detection engineers should optimize early, filter by time and entity, and avoid using production hunts as exploratory data dumps.

Permissions can create blind spots. An analyst may be able to query some tables but not others. Email, endpoint, identity, and cloud app data can have different access requirements. If the team does not understand those boundaries, investigations can produce incomplete conclusions.

Schema differences also matter. Defender advanced hunting tables are not the same as Sentinel tables, even when KQL is used in both places. Joining data across systems requires care with timestamps, entity identifiers, device names, account formats, and casing.

Finally, be careful with custom detections. A query that is useful during a guided hunt may be too noisy as an always-on detection. Operational detections need tuning, suppression logic, ownership, and response playbooks.

The reporting anti-pattern is rewarding activity instead of consequence. A program that celebrates query count, alert count, or ticket closure can still miss the one linked identity and device chain that matters. The corrected metric is path clarity: how quickly the team can explain who acted, from which device, through which control, against which Azure resource, and what changed because of the investigation.

Best Practices

Create a set of investigation pivots that connect Azure events to Defender entities. Common pivots include account object ID, user principal name, device ID, IP address, cloud app, URL, file hash, and timestamp windows. Document how each pivot should be normalized.

Keep high-value hunts small and explainable. A hunt should answer a question, not prove that a query author understands every table. Start with a specific scenario such as privileged Azure change after risky sign-in, endpoint alert before cloud access, or suspicious email leading to cloud app activity.

Use custom detections only for repeatable risks. Before promoting a hunt, define severity, owner, expected volume, response steps, and tuning rules. Review detections after incidents and after false positives.

Use a simple routing rule for hunt outcomes. Treat a finding as an incident lane when it indicates active compromise or suspicious control-plane change. Treat it as a systemic control lane when it reveals a recurring weakness such as unmanaged devices reaching administrative paths. Treat it as an architecture debt lane when the hunt exposes missing telemetry, weak retention, or unclear ownership. Reclassify the lane when new evidence changes impact, likelihood, or response urgency.

Plan for retention explicitly. If your organization needs to investigate beyond 30 days, design the export or Sentinel path before the incident. Retention is difficult to retrofit under pressure.

Train analysts on time handling. Use UTC in queries and be clear when screenshots or portal results display local time. Timeline errors are one of the simplest ways to undermine an otherwise strong investigation.

Practical advanced hunting pivots

These examples run in Microsoft Defender XDR advanced hunting, not Azure Monitor Logs. They add identity, device, cloud app, and alert-evidence context around Azure investigations. Do not assume you can directly join to AzureActivity in Defender XDR unless Microsoft Sentinel tables are onboarded into the Defender portal and visible to your role.

1
2
3
4
5
6
7


let lookback = 1d;
let adminIndicators = dynamic(["Add member to role", "Add app role assignment", "Consent to application", "Update application"]);
CloudAppEvents
| where Timestamp >= ago(lookback)
| where IsAdminOperation == true or ActionType has_any (adminIndicators) or ActivityType has_any (adminIndicators)
| project Timestamp, AccountObjectId, AccountId, AccountDisplayName, Application, ActionType, ActivityType, IPAddress, CountryCode, OSPlatform, ObjectName, ObjectType
| order by Timestamp desc

1
2
3
4
5
6
7


let lookback = 1d;
let accountUpn = "admin@contoso.com";
DeviceEvents
| where Timestamp >= ago(lookback)
| where InitiatingProcessAccountUpn =~ accountUpn
| project Timestamp, DeviceName, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessSHA1, RemoteIP, RemoteUrl, ReportId
| order by Timestamp desc

1
2
3
4
5
6


let lookback = 7d;
AlertEvidence
| where Timestamp >= ago(lookback)
| where CloudPlatform =~ "Azure" or isnotempty(ResourceID) or EntityType in~ ("CloudResource", "AzureResource", "User", "Device")
| project Timestamp, AlertId, Title, Severity, ServiceSource, EntityType, EvidenceRole, AccountUpn, DeviceName, CloudResource, ResourceType, ResourceID, SubscriptionId
| order by Timestamp desc

The table boundary matters. Microsoft documents CloudAppEvents as Defender for Cloud Apps activity, DeviceEvents as Defender for Endpoint device events, and AlertEvidence as alert entities from Defender services and onboarded Sentinel workspaces. Use these as pivots from an Azure investigation, not as proof that all Azure control-plane data exists inside XDR.

🍺

Brewed Insight: Advanced hunting earns its place when it connects an Azure action back to a human and a device - the sign-in, the mailbox rule, the endpoint event - not when it just becomes a second console to run disconnected searches in.

Learn More

Designing Microsoft Sentinel Around Normalized Signals

Tue, 29 Sep 2026 00:00:00 +1000

After collection comes interpretation. Microsoft Sentinel can ingest data from many Azure, Microsoft, third-party, and custom sources, but raw ingestion alone does not make a detection program resilient. If every analytic rule is tightly coupled to one vendor table or one proprietary schema, the detection library becomes fragile.

Normalization is not a data-engineering luxury; it is how security content survives source diversity.

This post focuses on using normalized signals, especially the Advanced Security Information Model, to make Sentinel content more portable, readable, and maintainable.

The Mental Model

Microsoft Sentinel is most valuable when it becomes a security reasoning layer, not just a log bucket. Analysts and detection engineers need to ask questions that cut across sources: authentication, network sessions, process activity, audit events, file activity, DNS activity, and alerts. Those concepts are more stable than individual table names.

ASIM provides a normalization layer between diverse data sources and the people or content that use the data. Microsoft describes ASIM as following the robustness principle: be strict in what you send and flexible in what you accept. In practice, ASIM maps proprietary source telemetry into normalized schemas with consistent field names and meanings.

That matters because security operations rarely stay inside a single product boundary. An identity investigation may involve Microsoft Entra logs, endpoint data, firewall records, cloud app telemetry, and custom application logs. Without normalization, each investigation becomes a manual translation exercise. With normalization, the team can reason in common concepts.

The mental model is to separate source onboarding from detection intent. A source-specific parser should understand the source. A detection should express the behavior it cares about. That separation lets new sources improve existing content instead of requiring every rule to be rewritten.

How It Really Works

ASIM uses normalized schemas and parsers. The schemas define common event types such as authentication, DNS, network session, process event, audit event, file activity, and user management. Parsers map source-specific tables into those schemas. Sentinel content can then query normalized views rather than hard-coding every source table.

flowchart LR A[Source Tables] --> B[ASIM Parsers] B --> C[Normalized Schemas] C --> D[Analytics Rules] C --> E[Hunting Queries] C --> F[Workbooks] D --> G[Incidents]

There are two important normalization patterns. Query-time parsers present a normalized view over existing data without changing the original table. This is flexible and useful because parser fixes can apply to existing data. Ingest-time normalization writes data into normalized tables, which can improve query performance for large or frequently used data sets.

The trade-off is familiar: flexibility versus performance and operational complexity. Query-time parsing is often easier to adopt and iterate. Ingest-time normalization may be better for high-volume, high-value schemas where query performance and cost predictability matter.

Sentinel content should be designed around source-agnostic intent where possible. For example, a brute-force detection should care about authentication failure and success patterns, entities, result codes, and source addresses. It should not need a separate rule for every identity source if normalized authentication events can represent the behavior consistently.

Normalization does not remove the need to understand source detail. It reduces unnecessary coupling. Detection engineers still need to know where fields came from, which parser versions are in use, how timestamps behave, and where source-specific semantics matter.

Real-World Impact

The biggest operational gain is maintainability. Without normalization, each new telemetry source increases detection library complexity. A new firewall, identity provider, or endpoint source may require duplicate rules, duplicate workbooks, and duplicate hunting queries. With normalized schemas, new sources can expand the coverage of existing content.

During an investigation, normalization reduces cognitive load. Analysts can ask consistent questions: what account, what source, what destination, what action, what result, what device, what process? They do not need to memorize every vendor-specific column before they can make progress.

Normalization also improves content governance. Detection owners can define which rules are source-specific and which are source-agnostic. They can track parser health as part of telemetry readiness. They can test whether onboarding a new source improves coverage for existing analytics. That is a more mature operating model than counting connectors.

For hybrid and multi-cloud environments, ASIM is especially useful. Azure environments often coexist with on-premises systems, SaaS platforms, endpoint telemetry, and other clouds. A Sentinel program that assumes all security data looks like Azure-native data will struggle. A normalized program can accept diversity without letting it dominate every rule.

There is also a resilience benefit. Vendors change schemas, teams replace tools, and log sources evolve. Normalization creates a buffer between source churn and detection intent. The buffer is not perfect, but it gives security engineering a place to manage change deliberately.

Gotchas and Edge Cases

The first gotcha is believing normalization is automatic. Deploying Sentinel does not mean every source is normalized. You need to know which parsers exist, which sources they support, which schemas are relevant, and whether your content actually uses them.

The second gotcha is ignoring parser quality. A normalized field is only useful if it is mapped correctly. If source semantics are misunderstood, normalized content can produce misleading results. Parser validation should be part of onboarding, especially for custom sources.

Performance can also surprise teams. Query-time parsers are flexible, but complex parsing over large data sets can slow queries. High-volume detections may need optimization, summarized data, or ingest-time normalization. A beautiful normalized query that times out is not operationally useful.

Another edge case is over-normalization. Some detections depend on source-specific nuance. Forcing everything through a common schema can hide details that matter. The right pattern is not “only ASIM.” It is “use normalized schemas where the behavior is common, and keep source-specific logic where the source detail changes the decision.”

Finally, ownership matters. Parsers, workbooks, analytic rules, and connectors are often managed by different people. If nobody owns the normalization layer, it will drift. Treat parser health and schema coverage as part of the Sentinel platform.

Best Practices

Build an ASIM adoption map. List the detection domains you care about, such as authentication, network, process, DNS, audit, and user management. Then map which data sources feed each domain, which parsers exist, and which rules use normalized schemas.

Prefer normalized content for common behavioral detections. Brute force, impossible travel, suspicious process patterns, DNS anomalies, and network session patterns are good candidates when the underlying schema supports them. Keep source-specific detections for source-specific capabilities.

Test parser output with known events. Do not validate only by checking that a parser returns rows. Validate entity fields, action fields, result fields, timestamps, source and destination fields, and error handling. Analysts need meaning, not just rows.

Monitor query performance. If a normalized query becomes a core analytic rule, measure execution time and cost. Consider optimization or ingest-time normalization for high-volume paths.

Document the contract. Detection content should state whether it depends on ASIM, which schema it expects, which sources are covered, and what assumptions are made. That documentation helps future engineers avoid breaking detection coverage during source changes.

Practical ASIM-aligned authentication query

This example uses the Microsoft Sentinel imAuthentication filtering parser so the detection intent is expressed through ASIM authentication fields rather than one source table. It looks for a common investigation pattern: many failed logons followed by a success for the same target user and logon method.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


let lookback = 1d;
let failureThreshold = 10;
imAuthentication(starttime = ago(lookback), endtime = now())
| where EventType == "Logon"
| where EventResult in ("Failure", "Success")
| summarize
 FailedLogons = countif(EventResult == "Failure"),
 SuccessfulLogons = countif(EventResult == "Success"),
 FirstSeen = min(EventStartTime),
 LastSeen = max(EventEndTime),
 SourceIps = make_set(SrcIpAddr, 10),
 Products = make_set(EventProduct, 10)
 by TargetUsername, TargetUserId, LogonMethod
| where FailedLogons >= failureThreshold and SuccessfulLogons > 0
| project TargetUsername, TargetUserId, LogonMethod, FailedLogons, SuccessfulLogons, FirstSeen, LastSeen, SourceIps, Products
| order by FailedLogons desc

The source assumption is that your workspace has authentication sources covered by supported ASIM parsers. Microsoft documents fields such as EventType, EventResult, EventStartTime, EventEndTime, TargetUsername, TargetUserId, LogonMethod, and SrcIpAddr in the ASIM authentication schema. Before promoting this to an analytic rule, test it with known events and confirm the parser maps your identity sources correctly.

🍺

Brewed Insight: Normalization is working when a new source improves detection coverage without forcing the team to relearn the entire investigation model - not when it becomes a new set of hunting queries nobody else can maintain.

Learn More

Collecting Azure Resource Logs Without Creating Noise

Thu, 24 Sep 2026 00:00:00 +1000

Once the Azure control plane is visible, the next question is which resource-level signals deserve to be collected. This is where many telemetry programs become expensive and disappointing. Teams enable every diagnostic category they can find, send it all to one workspace, and then discover that most of the data is not tied to a detection, investigation, or assurance use case.

A good Azure telemetry design is selective by intent, not selective by accident.

Diagnostic settings are the bridge between Azure resources and operational destinations such as Log Analytics, Event Hubs, and storage accounts. They are powerful, but they need architecture. Collection should be driven by risk, investigation paths, and response ownership.

The Mental Model

Think of resource logs as evidence from the services that carry business risk. The control plane tells you that a resource changed. Resource logs tell you how that resource behaved. For security telemetry, the question is not “can this service emit logs?” The question is “which emitted events would change a detection, investigation, or governance decision?”

This shifts the conversation from log categories to decisions. For a key vault, useful questions include who accessed secrets, whether access was denied, whether purge protection matters, and whether administrative changes align with policy. For a firewall or application gateway, useful questions include what was allowed, what was denied, which rules matched, and whether traffic patterns changed. For storage, useful questions include access paths, authentication methods, network source, and data access patterns.

The mental model is signal portfolio management. Some logs are high-value and low-volume. Some are high-value but expensive. Some are operationally useful but rarely security relevant. Some only matter during a major incident. Treating them all equally creates cost pressure and weakens analyst focus.

An architecture-first approach classifies resource logs into tiers: mandatory security evidence, conditional investigation support, operational-only telemetry, and excluded noise. That classification should be visible in platform standards, not hidden in individual diagnostic settings.

How It Really Works

Diagnostic settings define which log categories and metrics are collected from a resource and where they are sent. A single resource can have diagnostic settings that route data to destinations such as a Log Analytics workspace, an Event Hubs namespace, or a storage account. Each destination supports a different operating model.

flowchart TD A[Azure Resource] --> B[Diagnostic Setting] B --> C[Log Analytics Workspace] B --> D[Event Hubs] B --> E[Storage Account] C --> F[Sentinel Detections] D --> G[SIEM or Data Pipeline] E --> H[Archive and Retention]

Log Analytics is commonly used when teams need query, detection, workbook, and Microsoft Sentinel integration. Event Hubs is useful when telemetry must be streamed to another platform, a downstream security data lake, or a central enterprise pipeline. Storage can support archive and compliance retention patterns, although it is less convenient for active detection.

The critical design choice is not only destination. It is category selection. Azure services expose different diagnostic categories, and not all categories have equal security value. A storage account, key vault, firewall, application gateway, Kubernetes service, or database service will each require a different collection decision. Copying the same diagnostic template everywhere is rarely correct.

At scale, deployment matters. Azure Policy can deploy diagnostic settings for supported resources and can audit resources that are missing expected settings. Infrastructure as code can also define diagnostic settings alongside the resource. The most mature pattern is to combine both: templates create the expected configuration at deployment time, and policy detects drift or resources created outside the normal path.

Cost management must be part of the design. Ingestion volume, retention, table plan choices, and query behavior all affect the operating cost. Security teams need enough telemetry to investigate and detect, while platform teams need predictable cost boundaries. That trade-off should be explicit.

Real-World Impact

Diagnostic setting design directly affects incident response. During a suspected data exposure, the team may need to know whether storage data access logs were collected, whether key vault access was visible, whether firewall traffic was retained, and whether the data is queryable in the same workspace as related identity and control-plane events.

If the logs are missing, the investigation becomes a reconstruction exercise. If the logs exist but are split across disconnected destinations, response slows down. If the logs exist but are buried under unclassified noise, analysts spend time filtering rather than deciding. A deliberate collection design improves all three outcomes.

There is also a governance impact. When diagnostic settings are standardized, security and platform leaders can measure telemetry coverage. They can report which subscriptions and resource classes meet the logging baseline, where exceptions exist, and whether those exceptions have owners. That is much stronger than a general statement that “logging is enabled.”

For detection engineering, resource logs unlock higher-fidelity analytics. A network rule change from Activity Log is useful. A rule change followed by unusual allowed traffic from a firewall is more useful. A key vault configuration change is useful. The same change followed by denied secret reads, successful reads from a new identity, or access from an unexpected network is more useful again.

The impact is not just better alerting. It is better prioritization. Resource logs help teams decide which control-plane changes matter most because they show whether the affected service behaved differently afterwards.

Gotchas and Edge Cases

Diagnostic settings can fail as an operating model when ownership is unclear. Security may define the requirement, platform may own policy, application teams may own the resource, and operations may own the workspace. Without clear responsibility, gaps persist because everyone assumes another team is handling them.

Another gotcha is over-collection. Sending every metric and log category to a central workspace can create cost and performance issues without improving detection. More data can actually reduce security value if analysts cannot tell which tables matter or if high-value events are buried under routine operational records.

Service differences are also important. Azure services do not all expose the same diagnostic categories, and category names can evolve. A policy that works for one resource type may not apply to another. Treat resource classes individually and review high-risk services more often.

Log size and limits matter. Some destinations and services impose practical limits, and large records or high-volume categories can behave differently than expected. Defender for Cloud continuous export, for example, notes that Log Analytics supports records up to a specific size limit. That kind of detail matters when designing downstream pipelines.

Finally, do not forget the security of the telemetry path itself. A workspace, event hub, or storage account receiving security logs is a high-value target. If an attacker can modify diagnostic settings, delete data, or change routing, they can damage your evidence trail. Protect the collection pipeline with the same seriousness as production infrastructure.

Best Practices

Start by defining a resource telemetry baseline for high-risk Azure services. Key Vault, Storage, networking services, identity-adjacent services, Kubernetes, databases, and internet-facing services usually deserve early attention. For each resource class, document the mandatory categories, optional categories, destination, retention, and reason for collection.

Use policy to audit and deploy diagnostic settings where supported. Pair that with infrastructure as code so new resources are born with the expected telemetry configuration. Review policy exemptions as security exceptions, not administrative clutter.

Route telemetry based on use case. Send detection and investigation data to Log Analytics and Sentinel. Stream enterprise integration data to Event Hubs where needed. Use archive destinations for long-term retention requirements. Avoid one-size-fits-all routing.

Create a cost feedback loop. Track ingestion by resource type, category, subscription, and owner. If a category is expensive, either prove its security value or redesign the route. Cost control should not mean blind deletion; it should mean evidence-based collection.

Test the baseline with incident scenarios. Pick scenarios such as secret access, public exposure, firewall rule changes, and suspicious administrative updates. Confirm that the necessary logs are present, queryable, retained, and understandable by the teams who will use them.

Practical tiered diagnostic-settings baseline

The implementation pattern I prefer is a resource-class baseline with two tiers: mandatory evidence that is always collected, and investigative telemetry that is enabled only where the service, risk, and cost model justify it. This Key Vault example uses the Microsoft.Insights/diagnosticSettings@2021-05-01-preview Bicep resource, the Microsoft-documented Audit category group for mandatory evidence, and allLogs for the deeper tier.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


param keyVaultName string
param logAnalyticsWorkspaceId string

@allowed([
 'mandatoryEvidence'
 'investigative'
])
param telemetryTier string = 'mandatoryEvidence'

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
 name: keyVaultName
}

resource diagnosticSetting 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
 name: 'set-by-platform-security-baseline'
 scope: keyVault
 properties: {
 workspaceId: logAnalyticsWorkspaceId
 logAnalyticsDestinationType: 'Dedicated'
 logs: telemetryTier == 'mandatoryEvidence' ? [
 {
 categoryGroup: 'Audit'
 enabled: true
 }
 ] : [
 {
 categoryGroup: 'allLogs'
 enabled: true
 }
 ]
 metrics: [
 {
 category: 'AllMetrics'
 enabled: false
 }
 ]
 }
}

At scale, wrap this decision in Azure Policy DeployIfNotExists assignments and remediation tasks, but do not pretend one diagnostic setting fits every resource provider. Category groups are not universal, category names can differ by service, and allLogs can change cost materially. The baseline should say which resource classes require audit evidence, which classes justify investigative categories, and which teams own exceptions.

🍺

Brewed Insight: Diagnostic settings aren’t a checkbox to tick during deployment. They’re the contract between Azure services and the security decisions your organization is going to need to make later - usually at 2am, during an incident, when it’s too late to go back and turn on the log you needed.

Learn More

Azure Security Telemetry: Start with the Control Plane

Tue, 22 Sep 2026 00:00:00 +1000

Security telemetry programs often begin with tools, dashboards, and alert rules. That is understandable, but it can push teams into collecting data before they know what the data is supposed to prove. In Azure, the better starting point is the control plane: who changed what, where, when, and through which path.

If you cannot explain control-plane activity, you do not yet have a defensible Azure security telemetry model.

This first post in the Azure Security Telemetry series sets the foundation. We are not trying to collect every possible log. We are defining the minimum trustworthy signal set that helps platform, security, and operations teams reason about Azure change.

The Mental Model

Think of Azure security telemetry as three connected layers. The first layer is intent: management operations, policy changes, role assignments, deployments, and configuration updates. The second layer is resource behavior: logs and metrics emitted by the workloads and services affected by those changes. The third layer is detection context: the alerts, incidents, investigations, and response actions that turn raw events into security decisions.

The control plane sits in the intent layer. Azure Activity Log records subscription-level events such as administrative operations, service health events, and resource health changes. That makes it the audit backbone for questions like: who changed a network security group, who modified a key vault access model, who assigned a privileged role, or who deleted a diagnostic setting?

The mistake is treating Activity Log as just another table. It is not simply “more logs.” It is the record of management authority being exercised. A denied data exfiltration attempt matters, but so does the control-plane change that opened the path for it. A risky deployment matters, but so does the identity and pipeline that submitted it.

For senior cloud and security leaders, the mental model should be accountability before analytics. Start by mapping the decisions you must defend: privileged access, policy exceptions, logging coverage, network exposure, data protection posture, and incident response authority. Then collect the control-plane signals that let you prove those decisions are operating as intended.

How It Really Works

Azure gives you some control-plane visibility by default, but durable security telemetry still requires deliberate routing. Platform metrics and activity logs exist automatically, while diagnostic settings are used to send activity logs, resource logs, and metrics to destinations such as Log Analytics workspaces, Event Hubs, or storage accounts. For security operations, the common pattern is to send security-relevant control-plane logs into a central Log Analytics workspace that is connected to Microsoft Sentinel.

flowchart LR A[Azure Subscription] --> B[Activity Log] A --> C[Resource Diagnostic Settings] B --> D[Central Log Analytics Workspace] C --> D D --> E[Microsoft Sentinel] D --> F[Security Dashboards] E --> G[Analytics Rules and Incidents]

The important implementation detail is scope. Activity Log helps at the subscription level, but many useful resource logs require diagnostic settings on the individual resource, resource group, or supported platform service. That means your logging design must account for scale. If diagnostic settings are configured by hand, they will drift. If they are configured through policy, infrastructure as code, and landing zone standards, they can become part of the platform contract.

You also need to separate collection from interpretation. The collection design answers: what should be sent, where should it go, how long should it be retained, and which teams can read it? The interpretation design answers: which events matter, how should they be enriched, when should they alert, and which response path owns them?

The control-plane baseline should include administrative operations, policy and initiative changes, role assignment changes, diagnostic setting changes, network control updates, key vault configuration changes, security control changes, and major resource lifecycle events. The exact list varies by environment, but the principle does not: if a change can materially alter security posture, it should leave a searchable trail.

Real-World Impact

The practical value of control-plane telemetry is speed and confidence during incidents. When something looks wrong, teams should not spend the first hour arguing whether the platform changed. They should be able to reconstruct the management timeline quickly.

A common example is storage exposure. A storage account suddenly allows broader network access, public access is changed, or diagnostic coverage disappears. Without control-plane telemetry, the investigation starts with speculation. With it, the team can see the resource update, caller identity, caller IP, operation name, status, correlation ID, and timestamp. That does not solve the incident by itself, but it gives the response team a defensible timeline.

Another example is privileged access. If a high-impact role assignment appears, the important question is not only whether the role exists. It is who assigned it, through which mechanism, whether it matched an approved change, whether Privileged Identity Management was involved, and whether related resources changed afterwards. Activity Log and identity telemetry together make that analysis possible.

This also changes executive reporting. Instead of saying “we collect Azure logs,” the platform team can say “we can reconstruct privileged and security-relevant management changes across production subscriptions.” That is a stronger assurance statement because it is tied to decision quality, not data volume.

Control-plane telemetry is also valuable for engineering discipline. When deployment pipelines, policy assignments, and manual portal actions are visible in the same workspace, teams can identify where change is automated, where exceptions happen, and where operational habits are creating risk. The telemetry becomes a feedback loop for platform maturity.

Gotchas and Edge Cases

The control plane looks simple until you operate it across many subscriptions, tenants, regions, and teams. The hard parts are not usually about whether Azure can emit logs. They are about consistency, ownership, cost, and retention.

The first gotcha is assuming that default visibility is the same as a security telemetry design. Azure provides useful default signals, but default availability does not guarantee central retention, Sentinel integration, least-privilege access, or detection coverage. A log that exists somewhere but cannot be queried by the incident team is not operationally useful.

The second gotcha is inconsistent diagnostic settings. Many Azure services require explicit diagnostic settings to export resource logs. If these are created manually, some resources will be covered and others will not. If your detection rules depend on a log category that only exists on half the resources, the rule creates false confidence.

The third gotcha is treating every operation as equal. A noisy stream of benign write operations can bury the few events that matter. Control-plane telemetry needs classification. Privileged access changes, policy changes, network exposure changes, logging changes, and security tooling changes deserve a different review path from routine tag updates.

Retention is another edge case. Security investigations often need to look beyond a short operational window, especially when a compromise is discovered late. Retention choices should be deliberate and risk-based. Sending everything to a premium workspace forever is rarely the answer, but neither is keeping only a few days of high-value administrative history.

Finally, watch for cross-tenant and centralized operations. Enterprises often centralize logging, security operations, or event streaming. That is powerful, but it introduces permission, routing, and accountability questions. The target workspace or event hub must be protected as a security asset.

Best Practices

Begin with a written signal contract. Define the control-plane events that are security relevant for your organization, the subscriptions in scope, the destination workspace, the retention class, and the owning team. Make the contract understandable enough that cloud platform engineers and security analysts can both challenge it.

Use Azure Policy or infrastructure as code to deploy diagnostic settings at scale wherever possible. Manual setup is acceptable for early discovery, but it should not become the operating model for production. Policy also helps detect drift when teams create new resources without the expected telemetry path.

Design the workspace access model intentionally. Security analysts need enough access to investigate, but broad workspace access can expose sensitive operational data. Use role-based access control, table-level patterns where appropriate, and a clear distinction between readers, detection engineers, platform operators, and workspace administrators.

Classify events before alerting. Not every write operation is an incident. Build analytic logic around high-impact operations, unexpected actors, unusual locations, after-hours changes, failed administrative attempts, and changes to logging, identity, network, and security controls. Use allow lists carefully and review them regularly.

Correlate control-plane activity with identity and resource telemetry. An administrative operation becomes more meaningful when you can connect it to sign-in behavior, workload behavior, Defender findings, or Sentinel incidents. The goal is not a bigger query. It is a more reliable story.

Practical control-plane reconstruction query

Use this as a starting point in Azure Monitor Logs or Sentinel when Azure Activity Log has been routed into the AzureActivity table. It focuses on security-relevant management operations and returns the actor, correlation, operation, target, result, and time fields needed for a defensible change timeline.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


let lookback = 14d;
let securityRelevantOperations = dynamic([
 "Microsoft.Authorization/roleAssignments/write",
 "Microsoft.Authorization/roleAssignments/delete",
 "Microsoft.Authorization/policyAssignments/write",
 "Microsoft.Authorization/policyExemptions/write",
 "Microsoft.Insights/diagnosticSettings/write",
 "Microsoft.Insights/diagnosticSettings/delete",
 "Microsoft.Network/networkSecurityGroups/securityRules/write",
 "Microsoft.KeyVault/vaults/write",
 "Microsoft.Storage/storageAccounts/write",
 "Microsoft.Security/pricings/write"
]);
AzureActivity
| where TimeGenerated >= ago(lookback)
| where CategoryValue in ("Administrative", "Policy", "Security")
| where OperationNameValue in~ (securityRelevantOperations)
 or OperationNameValue has_any ("diagnosticSettings", "roleAssignments", "policyAssignments", "networkSecurityGroups", "keyVault", "storageAccounts")
| extend AuthorizationAction = tostring(Authorization_d.action),
 AuthorizationScope = tostring(Authorization_d.scope),
 RequestMethod = tostring(HTTPRequest.method),
 ClientRequestId = tostring(HTTPRequest.clientRequestId),
 ClaimsAppId = tostring(Claims_d.appid),
 ClaimsUpn = tostring(Claims_d.upn)
| project TimeGenerated, Caller, ClaimsUpn, ClaimsAppId, CallerIpAddress, CorrelationId, OperationId, OperationNameValue, ActivityStatusValue, ActivitySubstatusValue, SubscriptionId, ResourceGroup, ResourceProviderValue, ResourceId, AuthorizationAction, AuthorizationScope, RequestMethod, ClientRequestId
| order by TimeGenerated desc

The assumption is that AzureActivity contains subscription-level or management group level events routed to the workspace. Microsoft documents CorrelationId as the field that groups events belonging to the same broader action, while OperationNameValue, ResourceId, Caller, CallerIpAddress, ActivityStatusValue, and TimeGenerated provide the core reconstruction frame. Validate provider-specific operations in your tenant before turning this into an alert.

🍺

Brewed Insight: The first real win I look for in an Azure security telemetry program isn’t the number of logs collected. It’s whether the team can explain a security-relevant change without relying on memory, screenshots, or tribal knowledge.

Learn More

Operating an Azure Exposure Management Program

Thu, 17 Sep 2026 00:00:00 +1000

Most Azure security programs can produce long finding lists, but many struggle to prove that remediation work actually reduced exploitable paths. This post is about program governance, KPIs, and cross-team execution, and it takes an explicit stance: exposure management should be judged by attacker-path reduction, not by alert closure volume.

My default assessment rule is simple: if a fix does not measurably reduce attacker reachability or blast radius, it should not outrank work that does. I still value hygiene and control coverage, but I treat those as supporting factors unless they materially change external attack opportunity.

The Mental Model

Exposure management is a control loop, not a scanner report. The loop is discovery, context enrichment, prioritization, execution, and verification. Most teams perform discovery and sometimes prioritization. Fewer teams enforce a verification step that proves risk was actually reduced after deployment.

I assess maturity with three questions. First, can we explain who owns each internet-facing asset? Second, can we prove why one finding should be fixed before another? Third, can we show before-and-after evidence that the top remediation items removed realistic attacker options? If the answer to any question is no, the program is still dashboard-centric.

For this domain, I recommend a decision model rather than ad-hoc triage:

Program Effectiveness Index (PEI)

Formula: PEI = Weighted(High-Risk MTTR, Recurrence Percent, Known Owner Coverage, Exception Expiry Compliance)

This model is intentionally opinionated. It avoids the trap where a high CVSS issue on a low-consequence endpoint steals time from a medium-severity issue that sits on a short path to critical identity or data assets.

flowchart LR A[External Asset Discovery] --> B[Context Enrichment] B --> C[Program Effectiveness Index (PEI) Scoring] C --> D[Remediation Lane Routing] D --> E[Verification and Evidence] E --> F[Weekly Governance Review] F --> B

How It Really Works

In implementation, teams first establish asset identity quality: hostname, service owner, business criticality, internet reachability, and data sensitivity. If any one of these is missing, triage confidence drops and ownership handoffs stall. This is why I prefer failing ownership quality early instead of pretending the queue is decision-ready.

Next, findings are scored with the model above and placed into deterministic remediation lanes. A practical lane design is 24-hour, 72-hour, and 14-day SLA classes. Lane assignment should be automatic based on score bands and exception triggers, not manually debated in every stand-up.

I make one explicit tie-breaker statement here: when two items have similar score, prioritize the item with higher transitive reachability into identity, secrets, or control-plane operations. That tie-break rule helps avoid local optimization where teams close many low-impact issues and defer the path that matters most.

Assertion: In mature exposure programs, prioritization quality matters more than queue throughput, because incorrect prioritization increases attacker opportunity even when closure counts look healthy.

I route every program-level finding into one of three lanes, and I reclassify the moment measured outcomes change. Lane 1 (path-break) is for any single finding, anywhere in the program, that reopens a route to tier-0 identity or data - it escalates past normal SLA review straight to executive visibility. Lane 2 (systemic control) is for a KPI that’s trending the wrong way across multiple teams, such as exception-expiry compliance slipping in more than one business unit - these trigger a program-level root-cause review, not a team-by-team scolding. Lane 3 (architecture debt) is for known structural gaps, like inconsistent asset ownership data across subsidiaries, that need multi-quarter investment rather than urgent action.

I put a hard checkpoint on Lane 3 items specifically, because architecture debt is where programs quietly go to die: every Lane 3 item gets a 90-day milestone review, and if the milestone is missed twice, it is reclassified into Lane 2 and given an executive owner. I will not let “we’re working on it long-term” survive past two missed checkpoints - that’s not governance, that’s a program pretending a known gap doesn’t need a deadline.

The final step is verification. I require evidence of reduced exposure, such as closed reachable path, revoked external trust, removed vulnerable endpoint, or measurable drift reduction in telemetry. If evidence is missing, I treat the item as unresolved.

Real-World Impact

Teams that adopt this decision model generally reduce disagreement cycles between security and engineering. Instead of arguing over labels, they argue over measurable path consequence, which is a better use of time.

A representative operational pattern looks like this:

Map top 50 internet-facing findings into the model.
Auto-route into SLA lanes with owner assignment.
Require verification artifact for closure.
Review exceptions weekly with expiry discipline.

The impact is usually seen in three metrics: shorter high-risk MTTR, lower recurrence of previously fixed classes, and improved known-owner coverage for external assets. That combination provides stronger assurance than raw ticket closure counts.

This is the comparison I put in front of the steering committee: a program that closes 500 findings across the quarter looks impressive in a slide, but it means little if the one repeat offender - a business unit with chronically expired exceptions on tier-0 services - never gets addressed. I will spend a governance conversation on that one business unit over celebrating the aggregate closure number. If your program reporting can’t separate volume from concentrated risk, it’s activity reporting, not program management.

I’ll say plainly what most steering committees won’t: a program with a declining PEI score and a rising closure count is not improving, it’s getting better at closing easy things while the hard, concentrated risk sits untouched. I’d rather report a flat closure count with a rising PEI than the reverse, and I will defend that trade-off in front of any executive who pushes back on throughput.

Gotchas and Edge Cases

The biggest failure mode is pretending the scoring model is objective when inputs are stale. If criticality or ownership metadata lags behind architecture change, the model can produce confidently wrong priorities.

Another edge case is exception inflation. If teams can continuously renew exceptions without demonstrating compensating controls, the exposure program becomes a reporting layer rather than a risk-reduction engine.

A third edge case is over-automation. Automation is powerful for routing and evidence capture, but premature hard enforcement can break delivery workflows and create silent bypass behavior. I recommend phase-gated enforcement with transparent policy criteria and rollback paths.

The anti-pattern that undermines the most programs I’ve reviewed is a steering-committee report built around total findings closed program-wide. That number rewards volume and can rise even while one business unit’s exception backlog quietly rots on a tier-0 service. The metric that should anchor the report is exception-expiry compliance and MTTR broken out by business unit, not a single blended program-wide average.

Hard exception rule for this post: If exception-expiry compliance drops below 90 percent, suspend new exception approvals until the expired backlog is normalized.

Best Practices

Declare your assessment doctrine in writing and keep it visible in every remediation review.
Keep scoring inputs small and auditable so teams trust the model.
Separate score computation from policy overrides; both should be explicit.
Require one owner and one due date for every high-consequence finding.
Enforce evidence-based closure to avoid optimistic status updates.
Time-box exceptions and require compensating controls before approval.
Recalculate scores on architecture change events, not only on scan cycles.
Publish weekly trend deltas for MTTR, recurrence, and owner coverage.

🍺

Brewed Insight: My default rule is to prioritize attacker-path consequence over alert volume. Program maturity is proven by declining attacker opportunity, not by how many tickets closed this quarter.

Learn More

Continuous Exposure Monitoring with Sentinel and Workbooks

Tue, 15 Sep 2026 00:00:00 +1000

Most Azure security programs can produce long finding lists, but many struggle to prove that remediation work actually reduced exploitable paths. This post is about operational monitoring, alerts, and executive reporting, and it takes an explicit stance: exposure management should be judged by attacker-path reduction, not by alert closure volume.

The Mental Model

For this domain, I recommend a decision model rather than ad-hoc triage:

Operational Risk Drift (ORD)

Formula: ORD = New High-Risk Findings/week + Reopened Findings + SLA Breach Rate

flowchart LR A[External Asset Discovery] --> B[Context Enrichment] B --> C["Operational Risk Drift (ORD) Scoring"] C --> D[Remediation Lane Routing] D --> E[Verification and Evidence] E --> F[Weekly Governance Review] F --> B

How It Really Works

Assertion: In mature exposure programs, prioritization quality matters more than queue throughput, because incorrect prioritization increases attacker opportunity even when closure counts look healthy.

I route every drift signal into one of three lanes, and I reclassify the moment new telemetry changes the picture. Lane 1 (path-break) is for a drift event that reopens reachability into identity, secrets, or control-plane operations - it triggers same-day escalation regardless of how the dashboard looks otherwise. Lane 2 (systemic control) is for a recurring drift pattern across multiple services, such as the same misconfiguration reappearing after remediation - these get a root-cause workbook and a staged fix, not repeated one-off tickets. Lane 3 (architecture debt) is for slow-moving drift that isn’t urgent yet, like a gradually rising SLA breach rate in a low-criticality workload - these get tracked with a review date, not buried in noise.

Real-World Impact

A representative operational pattern looks like this:

Map top 50 internet-facing findings into the model.
Auto-route into SLA lanes with owner assignment.
Require verification artifact for closure.
Review exceptions weekly with expiry discipline.

This is the trade-off I put in front of executives directly: a workbook showing 200 resolved alerts this month looks reassuring, but it tells you nothing if the one metric that matters - reopened findings on tier-0 services - is climbing. I’d rather present a dashboard with fewer green tiles and one honest red one than a wall of green that’s quietly hiding a worsening drift pattern. If the reporting can’t surface that distinction, it isn’t monitoring exposure - it’s monitoring activity.

Gotchas and Edge Cases

The anti-pattern I actively watch for is a workbook tuned to show alert-closure velocity as the headline metric. That framing rewards teams for clearing high volumes of low-consequence alerts while a slow-building, high-consequence drift trend goes unreported because it doesn’t move the weekly closure number. The metric that should lead the dashboard is reopened findings and drift on tier-0 services, not total alerts actioned.

Hard exception rule for this post: If ORD worsens for two consecutive weeks on tier-1 services, trigger incident review and pause non-critical internet-facing changes.

Best Practices

Declare your assessment doctrine in writing and keep it visible in every remediation review.
Keep scoring inputs small and auditable so teams trust the model.
Separate score computation from policy overrides; both should be explicit.
Require one owner and one due date for every high-consequence finding.
Enforce evidence-based closure to avoid optimistic status updates.
Time-box exceptions and require compensating controls before approval.
Recalculate scores on architecture change events, not only on scan cycles.
Publish weekly trend deltas for MTTR, recurrence, and owner coverage.

🍺

Brewed Insight: My default rule is to prioritize attacker-path consequence over alert volume. Once a team adopts a deterministic model plus a hard exception rule, remediation decisions get faster, more defensible, and more likely to actually reduce real external attack opportunity - not just clear the queue.

Learn More

Hardening Internet-Facing Assets with Policy and Automation

Thu, 10 Sep 2026 00:00:00 +1000

Most Azure security programs can produce long finding lists, but many struggle to prove that remediation work actually reduced exploitable paths. This post is about policy-driven remediation and automation patterns, and it takes an explicit stance: exposure management should be judged by attacker-path reduction, not by alert closure volume.

The Mental Model

For this domain, I recommend a decision model rather than ad-hoc triage:

Remediation Routing Score (RRS)

Formula: RRS = Control Gap Severity + Automation Feasibility + Recurrence Likelihood

flowchart LR A[External Asset Discovery] --> B[Context Enrichment] B --> C["Remediation Routing Score (RRS) Scoring"] C --> D[Remediation Lane Routing] D --> E[Verification and Evidence] E --> F[Weekly Governance Review] F --> B

How It Really Works

Assertion: In mature exposure programs, prioritization quality matters more than queue throughput, because incorrect prioritization increases attacker opportunity even when closure counts look healthy.

I route every control gap into one of three lanes, and I reclassify the moment automation coverage or exception status changes. Lane 1 (path-break) is for any internet-facing gap that’s both policy-enforceable and sits on a path to identity or control-plane access - it gets deny-by-default treatment immediately, no exception debate. Lane 2 (systemic control) is for a control gap that recurs across many resources because a policy definition is missing or too narrow - these get a policy fix at the platform level, not repeated manual remediation. Lane 3 (architecture debt) is for gaps that are real but low-consequence, like a redundant rule that could be simplified - these get a backlog item and a review date.

Real-World Impact

A representative operational pattern looks like this:

Map top 50 internet-facing findings into the model.
Auto-route into SLA lanes with owner assignment.
Require verification artifact for closure.
Review exceptions weekly with expiry discipline.

I make this comparison explicit when a team wants to celebrate hardening progress: automating fixes for 100 low-impact, redundant firewall rules is useful housekeeping, but it doesn’t outrank one policy change that closes the only permissive rule allowing direct internet access to a management interface. Given a choice between the two bodies of work in the same sprint, I take the one rule every time. If your hardening backlog can’t rank those two differently, it isn’t measuring consequence - it’s measuring rule count.

Gotchas and Edge Cases

The anti-pattern I push back on is a hardening dashboard that measures automation coverage percentage as the success metric - “92 percent of policies enforced.” That number can look excellent while the 8 percent gap contains the one permissive rule that actually matters. The metric that should be reported instead is whether every internet-facing, policy-enforceable gap tied to a known attack path has been closed, not the aggregate enforcement percentage.

Hard exception rule for this post: If the control gap is internet-facing and policy-enforceable, deny by default; exceptions must be time-bound with compensating controls.

Best Practices

Declare your assessment doctrine in writing and keep it visible in every remediation review.
Keep scoring inputs small and auditable so teams trust the model.
Separate score computation from policy overrides; both should be explicit.
Require one owner and one due date for every high-consequence finding.
Enforce evidence-based closure to avoid optimistic status updates.
Time-box exceptions and require compensating controls before approval.
Recalculate scores on architecture change events, not only on scan cycles.
Publish weekly trend deltas for MTTR, recurrence, and owner coverage.

🍺

Brewed Insight: My default rule is to prioritize attacker-path consequence over alert volume. A deterministic model plus a hard exception rule turns hardening from an argument about severity labels into a decision anyone on the team can defend.

Learn More

Prioritizing External Risk with Attack Path Context

Tue, 08 Sep 2026 00:00:00 +1000

Most Azure security programs can produce long finding lists, but many struggle to prove that remediation work actually reduced exploitable paths. This post is about risk prioritization with business impact and attack path evidence, and it takes an explicit stance: exposure management should be judged by attacker-path reduction, not by alert closure volume.

The Mental Model

For this domain, I recommend a decision model rather than ad-hoc triage:

Attack Path Priority (APP)

Formula: APP = Exploitability x Path Reduction Potential x Business Impact

flowchart LR A[External Asset Discovery] --> B[Context Enrichment] B --> C[Attack Path Priority (APP) Scoring] C --> D[Remediation Lane Routing] D --> E[Verification and Evidence] E --> F[Weekly Governance Review] F --> B

How It Really Works

Assertion: In mature exposure programs, prioritization quality matters more than queue throughput, because incorrect prioritization increases attacker opportunity even when closure counts look healthy.

I route every prioritized finding into one of three lanes, and I reclassify the moment new attack-path evidence appears. Lane 1 (path-break) is for a finding that is the sole remaining route to a tier-0 identity or data asset - it outranks everything else in the queue by default, no scoring debate required. Lane 2 (systemic control) is for a class of findings that recur across many assets and all contribute partial exploitability, such as a shared misconfiguration pattern - these get a coordinated fix, not individual triage. Lane 3 (architecture debt) is for findings with real exploitability but no meaningful path to anything critical - these get tracked, not rushed.

Real-World Impact

A representative operational pattern looks like this:

Map top 50 internet-facing findings into the model.
Auto-route into SLA lanes with owner assignment.
Require verification artifact for closure.
Review exceptions weekly with expiry discipline.

Here’s the trade-off I make explicit whenever prioritization gets contested: closing 100 findings that all lead to dead-end, low-consequence endpoints looks like strong throughput, but it’s worth less than closing the 20 findings that collapse the only path to a tier-0 identity store. I will always choose the smaller batch that removes viable reachability over the larger batch that doesn’t. If two competing pieces of work are both labeled “high priority,” that tie-break - which one removes a real path - is the rule that should decide, not who asked first.

Gotchas and Edge Cases

The anti-pattern I actively correct is a risk report that ranks findings purely by CVSS score aggregated across the queue. That approach rewards raising the average severity number, not reducing real attacker opportunity, and it can bury the one moderate-severity finding that happens to sit on the only path to something critical. The metric that should drive the report is count of viable tier-0 paths remaining, not average or aggregate severity score.

Hard exception rule for this post: If a remediation removes the only transitive path to tier-0 identity or data, it outranks higher-volume findings by default.

Best Practices

Declare your assessment doctrine in writing and keep it visible in every remediation review.
Keep scoring inputs small and auditable so teams trust the model.
Separate score computation from policy overrides; both should be explicit.
Require one owner and one due date for every high-consequence finding.
Enforce evidence-based closure to avoid optimistic status updates.
Time-box exceptions and require compensating controls before approval.
Recalculate scores on architecture change events, not only on scan cycles.
Publish weekly trend deltas for MTTR, recurrence, and owner coverage.

🍺

Brewed Insight: My default rule is to prioritize attacker-path consequence over alert volume. A remediation that removes the only route to a tier-0 identity should outrank a dozen louder findings that lead nowhere - that’s the judgment call this model is built to defend.

Learn More

Discovering Shadow IT with Azure Exposure Management

Thu, 03 Sep 2026 00:00:00 +1000

Most Azure security programs can produce long finding lists, but many struggle to prove that remediation work actually reduced exploitable paths. This post is about shadow IT discovery and ownership mapping, and it takes an explicit stance: exposure management should be judged by attacker-path reduction, not by alert closure volume.

The Mental Model

For this domain, I recommend a decision model rather than ad-hoc triage:

Shadow Asset Risk Score (SARS)

Formula: SARS = Discoverability (0-5) + Data Sensitivity (0-5) + Trust Boundary Crossing (0-5)

flowchart LR A[External Asset Discovery] --> B[Context Enrichment] B --> C["Shadow Asset Risk Score (SARS) Scoring"] C --> D[Remediation Lane Routing] D --> E[Verification and Evidence] E --> F[Weekly Governance Review] F --> B

How It Really Works

Assertion: In mature exposure programs, prioritization quality matters more than queue throughput, because incorrect prioritization increases attacker opportunity even when closure counts look healthy.

I route every shadow asset into one of three lanes, and I reclassify the moment ownership or trust evidence changes. Lane 1 (path-break) is for any shadow asset with a confirmed trust relationship into production identity, secrets, or data - it enters containment the same day, regardless of how many other shadow assets are queued. Lane 2 (systemic control) is for a recurring discovery pattern, such as the same team repeatedly standing up unsanctioned SaaS integrations - these get an owner conversation and a staged fix, not a one-off takedown. Lane 3 (architecture debt) is for isolated, low-risk shadow assets with no trust boundary crossing - these get tracked and reviewed, not chased urgently.

Real-World Impact

A representative operational pattern looks like this:

Map top 50 internet-facing findings into the model.
Auto-route into SLA lanes with owner assignment.
Require verification artifact for closure.
Review exceptions weekly with expiry discipline.

Here’s the comparison I use to explain priority to skeptical stakeholders: discovering and cataloguing 100 harmless shadow assets in a quarter is a fine housekeeping exercise, but it matters far less than finding the one shadow asset with a live SSO trust into your production identity provider. I will pull an engineer off a backlog of 100 low-risk findings to deal with that one asset immediately. If your shadow IT program can’t tell the difference between those two situations, it’s an inventory exercise, not a risk-reduction program.

Gotchas and Edge Cases

The anti-pattern to watch for is a shadow IT program that reports success purely as discovery-count growth - “we found 400 new assets this quarter.” That number can go up while the program’s actual value goes down, because volume says nothing about consequence. The metric that should be reported instead is the count and age of shadow assets with a confirmed trust boundary crossing into production - that’s the number that tells you whether the program is reducing real risk.

Hard exception rule for this post: Any shadow asset with production SSO trust enters containment workflow immediately, even when SARS is only moderate.

Best Practices

Declare your assessment doctrine in writing and keep it visible in every remediation review.
Keep scoring inputs small and auditable so teams trust the model.
Separate score computation from policy overrides; both should be explicit.
Require one owner and one due date for every high-consequence finding.
Enforce evidence-based closure to avoid optimistic status updates.
Time-box exceptions and require compensating controls before approval.
Recalculate scores on architecture change events, not only on scan cycles.
Publish weekly trend deltas for MTTR, recurrence, and owner coverage.

🍺

Brewed Insight: My default rule here is the same one I use across exposure management: prioritize attacker-path consequence over alert volume. A shadow IT asset only becomes urgent the moment it’s linked to production trust - that’s the signal worth acting on, not the raw discovery count.

Learn More

Azure Attack Surface Management in Defender EASM

Tue, 01 Sep 2026 00:00:00 +1000

Most Azure security programs can produce long finding lists, but many struggle to prove that remediation work actually reduced exploitable paths. This post is about Defender EASM discovery and external asset inventory, and it takes an explicit stance: exposure management should be judged by attacker-path reduction, not by alert closure volume.

The Mental Model

For this domain, I recommend a decision model rather than ad-hoc triage:

Exposure Priority Score (EPS)

Formula: EPS = Internet Reachability (0-5) x Identity Proximity (0-5) x Asset Criticality (0-5)

flowchart LR A[External Asset Discovery] --> B[Context Enrichment] B --> C["Exposure Priority Score (EPS) Scoring"] C --> D[Remediation Lane Routing] D --> E[Verification and Evidence] E --> F[Weekly Governance Review] F --> B

How It Really Works

Assertion: In mature exposure programs, prioritization quality matters more than queue throughput, because incorrect prioritization increases attacker opportunity even when closure counts look healthy.

I route every EASM finding into one of three lanes, and I reclassify the moment new evidence changes the picture. Lane 1 (path-break) is for anything that collapses attacker reachability into identity, secrets, or control-plane operations in a single fix - it jumps the queue regardless of volume. Lane 2 (systemic control) is for weaknesses that recur across multiple discovered assets, such as a class of misconfigured endpoints EASM keeps surfacing - these get a staged remediation plan with milestones, not one ticket. Lane 3 (architecture debt) is for real but non-urgent issues, like inconsistent asset tagging that slows future triage - these get a review date, not silence.

Real-World Impact

A representative operational pattern looks like this:

Map top 50 internet-facing findings into the model.
Auto-route into SLA lanes with owner assignment.
Require verification artifact for closure.
Review exceptions weekly with expiry discipline.

I make this trade-off explicit with stakeholders because it’s the one they instinctively get wrong: closing 100 medium-severity findings on isolated marketing endpoints looks productive on a closure chart, but it does nothing if one unpatched authentication gateway still hands an attacker a direct route to domain admin. I will take the 20-finding batch that collapses that one path over the 100-finding batch that never touches it, every time. If a team can’t tell me which of the two batches removes more attacker reachability, they don’t have a prioritization model yet - they have a to-do list with a due date.

Gotchas and Edge Cases

The clearest anti-pattern I’ve watched teams fall into is a leadership dashboard that rewards closed-this-sprint counts without ever asking whether the closed findings reduced reachable attack paths. That KPI quietly trains teams to cherry-pick easy, low-consequence findings while the dangerous ones sit untouched because they’re harder to close quickly. The metric that actually matters is the trend in transitive reachability to tier-0 assets over time - even if it means fewer tickets close in a given week.

Hard exception rule for this post: If an internet-facing authentication surface has no confirmed owner, classify as P1 ownership triage within 24 hours regardless of EPS.

Best Practices

Declare your assessment doctrine in writing and keep it visible in every remediation review.
Keep scoring inputs small and auditable so teams trust the model.
Separate score computation from policy overrides; both should be explicit.
Require one owner and one due date for every high-consequence finding.
Enforce evidence-based closure to avoid optimistic status updates.
Time-box exceptions and require compensating controls before approval.
Recalculate scores on architecture change events, not only on scan cycles.
Publish weekly trend deltas for MTTR, recurrence, and owner coverage.

🍺

Brewed Insight: My default rule, after reviewing enough EASM queues, is to prioritize attacker-path consequence over alert volume. Once a team adopts a deterministic model plus a hard exception rule, remediation decisions get faster, more defensible, and more likely to actually shrink the attack surface an adversary can use - not just the number on the closure report.

Learn More

Governing Workload Identity: Review Cadence, Drift Detection, and Architecture Accountability

Thu, 27 Aug 2026 00:00:00 +1000

Identity architecture rarely fails in one dramatic design decision.

It fails quietly through small, reasonable exceptions that are never reconciled back to boundary intent.

That is why governance for workload identity cannot be a yearly policy check.

It has to be an operational architecture discipline.

The Mental Model

Governance is not inventory management. Governance is trust-state management.

Inventory answers what identities exist. Trust-state management answers what those identities can now reach and whether that reach still matches architectural intent.

Identity governance quality is measured by drift control, not by control documentation volume.

If your review cadence cannot detect boundary drift before incidents do, governance is procedural, not protective.

How It Actually Works

Drift appears through recurring operational patterns.

Exception accumulation

Temporary broad grants for release pressure, troubleshooting, or emergency access remain in place. Each exception is understandable alone, but cumulative effect widens trust boundaries.

Ownership fragmentation

Identity platform teams manage issuance controls while workload teams manage authorization scope. Without shared accountability, consequence-level risks move between teams unresolved.

Change-driven reachability growth

New services and dependencies are added under existing scopes, increasing effective reach without explicit identity redesign.

flowchart TD A[Initial identity design] --> B[Operational exceptions added] B --> C[Scope and dependency drift] C --> D{Governance trigger tied to architecture change?} D -->|No| E[Drift persists] D -->|Yes| F[Boundary review performed] E --> G[Compromise consequence grows] F --> H{Remediation executed?} H -->|No| G H -->|Yes| I[Trust boundary restored]

Effective governance interrupts this loop early and repeatedly.

When This Pattern Reduces Risk and When It Increases It

Reduces risk when

Review cadence is triggered by architecture change, not only calendar interval.
Drift signals are defined and measured (scope growth, exception age, transitive reach increase).
One accountable owner is named for trust consequence across mechanism and authorization layers.
Governance outputs include explicit boundary restoration decisions.

Increases risk when

Governance focuses on identity count and control checklist completion.
Exceptions are approved without expiry or rollback criteria.
Findings are written as observations instead of decision-required risk states.
Review outputs are disconnected from delivery backlog and ownership.

The governance anti-pattern is process maturity without consequence control.

A Decision Filter for Governance Reviews

Before closing any identity governance review, require answers to:

Which identity boundaries widened since the last review, and why?
Which exceptions are now older than their original risk acceptance window?
Which identities gained new transitive reach through platform change?
Which boundary restoration decisions were made, by whom, and by when?

If these answers are missing, the review was descriptive, not governing.

Real-World Impact

Strong governance changes outcomes because it continuously re-aligns trust reality with design intent.

Risk visibility quality

Leadership gets actionable risk visibility when drift is presented as boundary consequence and ownership decision, not as generic compliance status.

Engineering prioritization

Teams prioritize the right remediation work when governance findings map directly to containment impact and explicit owners.

Incident readiness

Organizations with drift-aware governance face fewer surprise pathways during incidents because problematic edges are identified earlier in normal operations.

Long-term architecture integrity

Regular boundary restoration prevents identity architecture from degrading into historical exception patterns that no one can confidently explain.

Gotchas and Edge Cases

These issues frequently weaken governance even when review meetings are consistent.

Calendar-driven reviews miss change-driven risk

Large identity risk shifts often happen between scheduled reviews. Triggering review on architecture change captures material drift sooner.

Metrics can be precise and still unhelpful

Tracking identity counts and policy coverage can look mature while failing to show expanding effective reach. Governance metrics must describe consequence.

Ownership can be explicit but mis-scoped

Assigning ownership to one platform team may still fail if workload-level authorization changes are outside that team’s control. Accountability must span the full trust path.

“Accepted risk” can become default posture

Risk acceptance without expiry criteria turns temporary trade-offs into standing architecture behavior. Governance must revisit and retire accepted risk states.

Best Practices

Tie governance triggers to architecture events

Run identity boundary reviews when new services, federated paths, or major scope assignments are introduced.

Track drift with consequence-oriented metrics

Measure effective reach expansion, exception age, and transitive dependency growth, then link each metric to remediation thresholds.

Publish review outcomes as decisions, not observations

Every governance review should end with explicit boundary actions, owners, and dates.

Maintain a standing boundary debt register

Treat broad scope and aging exceptions as debt with lifecycle rules. Debt without lifecycle becomes permanent exposure.

🍺

Brewed Insight: Identity governance only works when it continuously restores trust boundaries as systems change. Otherwise it’s just documenting drift on a schedule while the actual risk keeps growing underneath it.

Learn More

Designing for Blast Radius: Identity Segmentation as Containment Strategy

Tue, 25 Aug 2026 00:00:00 +1000

A mature identity architecture assumes compromise.

It does not hope compromise will not happen.

That assumption changes design priorities immediately: the objective becomes limiting consequence, not declaring prevention completeness.

For workload identity, that means blast radius is a design artifact.

The Mental Model

Blast radius is the maximum domain of legitimate action available to a compromised identity.

It is shaped by trust boundaries, scope inheritance, shared identity usage, and service dependencies.

Containment is not the absence of compromise. It is the presence of enforced stopping points.

If you cannot point to clear stopping points, your architecture has likely optimized for convenience over survivability.

How It Actually Works

Identity blast radius grows through boundary collapse.

Shared trust zones

When identities are reused across multiple workloads, one compromise crosses multiple business contexts. Shared usage reduces management overhead while increasing correlated impact.

Broad inherited authorization

Assignments at broad scopes make future assets reachable without additional design decisions. Blast radius silently grows with platform growth.

Dependency-coupled privilege

A narrowly scoped identity can still trigger broader action through dependent services. Containment must account for downstream authority, not only direct grants.

flowchart TD A[Identity compromise] --> B{Boundary model} B -->|Isolated by workload and zone| C[Localized impact] B -->|Shared identity across zones| D[Cross-zone movement] D --> E{Transitive dependencies constrained?} E -->|Yes| F[Moderate containment] E -->|No| G[High systemic blast radius] C --> H[Recoverable with local controls] F --> I[Containment with elevated effort] G --> J[Architecture-level failure]

This is why segmentation decisions are identity decisions, not only network decisions.

When This Pattern Reduces Risk and When It Increases It

Reduces risk when

Identity boundaries align to workload trust zones.
Shared identities are rare and tightly justified.
Cross-zone access paths are explicit exceptions with owner and expiry.
Dependency privileges are modeled in containment reviews.

Increases risk when

One identity is used to simplify multi-workload operations.
Scope is granted broadly to avoid repeated access changes.
Cross-zone exceptions become standing design defaults.
Containment reviews ignore transitive dependencies.

The practical failure mode is predictable: efficient operations create oversized compromise domains.

A Decision Framework for Containment Design

Use this filter before accepting workload identity design:

What is the smallest trust zone this identity must operate in?
Which assets become reachable if this identity is compromised today?
Which dependencies can amplify this identity beyond its direct scope?
Which boundary is guaranteed to stop movement, and what evidence confirms it?

If answers depend on assumptions instead of evidence, containment is not real yet.

Real-World Impact

Containment quality directly shapes business resilience under identity incidents.

Incident consequence

When identity boundaries are explicit and narrow, incidents stay local and recovery is faster. When boundaries are porous, one compromise can trigger multi-service disruption.

Recovery planning quality

Recovery plans become realistic when they map to actual containment boundaries. Without that mapping, recovery assumptions are often optimistic and fail under pressure.

Platform design trade-offs

Teams make better trade-offs when they quantify the operational savings of shared identities against the extra consequence they introduce under compromise.

Executive risk decisions

Leaders can prioritize architecture investments more effectively when blast radius is expressed as concrete affected domains instead of abstract severity labels.

Gotchas and Edge Cases

These conditions commonly weaken containment even when segmentation appears present.

Segmentation on paper can differ from segmentation in effect

Policy documents may describe isolated zones while inherited role assignments and service dependencies still permit cross-zone action. Effective reach must be tested, not assumed.

Emergency access paths often become permanent

Break-glass identity exceptions added for resilience can become permanent high-risk routes if owner and expiry controls are weak.

Shared observability and automation tooling can become hidden bridge layers

Tooling identities that span many zones can unintentionally reconnect segmented domains through operational pathways.

Business-critical services can pressure teams into broad identity reuse

When delivery urgency is high, teams may standardize on shared high-scope identities. This improves speed and quietly eliminates containment.

Best Practices

Segment identities by trust boundary first, ownership second

Team ownership matters, but compromise consequence should determine boundary design.

Make cross-zone identity use an exception contract

Every cross-zone path should include purpose, owner, review cadence, and removal criteria.

Test containment through scenario-based reviews

Use realistic compromise scenarios to validate where movement stops in practice.

Track blast-radius drift as a standing metric

Measure how many high-value domains each identity can reach over time. Rising reachability should trigger immediate design review.

🍺

Brewed Insight: Containment succeeds when identity compromise runs into an engineered stopping point - not when an architecture document simply describes segmentation intent that was never actually tested.

Learn More

Token Architecture as a Control Surface: Issuer, Audience, Scope and Lifetime

Thu, 20 Aug 2026 00:00:00 +1000

Most teams treat token settings as identity plumbing.

That view is expensive.

Issuer checks, audience constraints, token scope, and token lifetime decide how far a stolen or misused token can travel and how long it remains useful.

That is architecture, not plumbing.

The Mental Model

Tokens are permission containers with movement potential.

The real design question is not whether token issuance works. It is whether token use remains bounded under compromise.

Token architecture is the portability policy for authority under pressure.

If your token model allows broad audience acceptance, oversized scopes, and long-lived validity, you are designing for convenience over containment.

How It Actually Works

Four token controls shape consequence.

Issuer trust

Accepted issuers define who is allowed to mint authority your services will trust. Broad issuer acceptance expands the trust perimeter and raises dependency risk.

Audience constraints

Audience is the first portability boundary. Tight audience validation prevents reuse of valid tokens across unrelated services.

Scope and claims breadth

Wide scopes and over-rich claims increase usable privilege after compromise. Claims should be sufficient for function, not future-proofed for convenience.

Lifetime and refresh behavior

Long token lifetime increases misuse window. Extremely short lifetime can create availability fragility if issuance paths fail. The right value is a risk-and-resilience trade-off, not a default setting.

flowchart TD A[Token issued] --> B{Issuer accepted?} B -->|No| C[Reject] B -->|Yes| D{Audience exact match?} D -->|No| C D -->|Yes| E{Scope minimal?} E -->|No| F[Excess portability risk] E -->|Yes| G{Lifetime bounded?} G -->|No| H[Extended misuse window] G -->|Yes| I[Constrained token utility] F --> J[Containment weak] H --> J I --> K[Containment stronger]

This is why token policy belongs in architecture review, not only in implementation checklists.

When This Pattern Reduces Risk and When It Increases It

Reduces risk when

Issuer trust is explicit and minimal.
Audience checks are strict and service-specific.
Scopes map to current workload duties, not possible future duties.
Lifetime reflects both compromise exposure and issuance reliability.

Increases risk when

Services accept broad audience values “for interoperability”.
Scopes are expanded pre-emptively to avoid future integration work.
Token lifetime decisions are made without threat-window reasoning.
Refresh paths are trusted without resilience testing.

The recurring mistake is optimizing token convenience while assuming identity controls elsewhere will compensate.

A Decision Framework for Token Design

Use this review filter before approving token policy:

Which issuers are trusted, and why is each one necessary?
Can a token for service A be replayed against service B?
Which claims and scopes are mandatory for this workload now?
If a token is exfiltrated, what is the maximum damage window?

If the team answers these as implementation defaults instead of architectural decisions, containment is probably weaker than expected.

Real-World Impact

Token architecture decisions affect day-two operations as much as day-zero security posture.

Security posture quality

Organizations with disciplined audience and scope boundaries see smaller compromise domains because valid tokens do not travel as far.

Reliability trade-offs

Aggressive lifetime policies can reduce replay exposure but increase operational fragility when issuance dependencies are unstable. The right answer requires explicit trade-off decisions, not blanket hardening rules.

Engineering discipline

Teams that treat claims as contract design produce cleaner service boundaries. Teams that treat claims as convenience payloads accumulate hidden coupling and privilege debt.

Audit and review clarity

Token architecture with clear rationale creates faster, higher-confidence reviews. Ambiguous issuer and audience policy creates repeated debate and delayed decisions.

Gotchas and Edge Cases

These are frequent failure modes even in technically competent teams.

Strict audience checks can be bypassed by broad gateway trust

A service can validate audience correctly while an upstream gateway accepts overly broad tokens and forwards them. End-to-end token handling must be reviewed as one chain.

Overly short lifetimes can create fail-open pressure

When issuance dependencies degrade, teams may introduce emergency bypass paths that permanently weaken controls. Resilience planning is part of secure token design.

Scope creep often enters through “temporary” troubleshooting grants

Troubleshooting claims or broad scopes are often left in place after incidents. The token model then drifts from intentional design to accumulated exception state.

Multi-tenant federation can blur issuer accountability

When several issuers are accepted over time, teams may lose precision on which issuer protections are relied upon for which workloads. This raises assurance uncertainty.

Best Practices

Treat audience policy as a hard boundary

Design audience checks to enforce service-level trust segmentation, and test replay attempts across adjacent services.

Keep claims minimal and role-derived

Include only what services need to authorize current behavior. Avoid convenience claims that widen privilege interpretation.

Define token lifetime with explicit threat-window rationale

State the compromise window you are accepting and the resilience controls that justify it.

Review token paths after every identity architecture change

Any change in federation, gatewaying, or service coupling can alter portability risk. Token architecture needs recurring review, not one-time setup.

🍺

Brewed Insight: Token security was never about issuing valid tokens. It’s about making a valid token useless the moment it steps outside the exact boundary it was meant to operate in.

Learn More

Managed Identity and Federation: What They Solve and What the Architecture Still Owes You

Tue, 18 Aug 2026 00:00:00 +1000

Managed identity and federation are often presented as endpoint decisions.

Move off secrets. Adopt federation. Job done.

That is an operations milestone, not an architectural conclusion.

The hard work starts after those controls are in place.

The Mental Model

Managed identity and federation should be treated as trust transport mechanisms, not trust design mechanisms.

They change how claims are issued and consumed. They do not automatically define where authority should stop.

Credential modernization lowers one class of risk. Trust boundary design still determines systemic exposure.

This distinction matters because teams often report success at the mechanism layer while carrying unresolved architectural consequence at the scope layer.

How It Actually Works

Managed identity and federation improve different parts of the problem space.

Managed identity improvement domain

Managed identity removes secret handling burden: no application-held credentials, less rotation fragility, lower human credential exposure. That is significant and measurable.

Federation improvement domain

Federation enables external workload trust without long-lived secrets. It can reduce credential sprawl in CI/CD and multi-platform workloads, and it can improve auditability of issued claims.

Architecture debt that remains

Neither mechanism automatically constrains:

Effective role scope in Azure
Transitive service reachability
Cross-boundary trust expansion through inherited rights
Blast radius under valid token misuse

flowchart TD A[Identity mechanism upgraded] --> B{Secrets removed?} B -->|Yes| C[Credential theft surface reduced] B -->|No| D[Credential risk persists] C --> E{Scope and trust boundaries constrained?} E -->|Yes| F[Material exposure reduction] E -->|No| G[Architectural exposure remains] G --> H[Compromise consequence still high] F --> I[Defensible identity posture]

The chart is intentionally blunt: mechanism improvement without boundary control produces partial security.

When This Pattern Reduces Risk and When It Increases It

Reduces risk when

Mechanism changes are paired with scope redesign and dependency review.
Federated identities have explicit issuer, audience, and subject constraints.
Authorization boundaries are revalidated after identity modernization.
Teams track residual trust-graph risk as a first-class metric.

Increases risk when

Success criteria stop at “no secrets in code”.
Federation is introduced with broad authorization to avoid integration friction.
External assurance and internal authorization are blended into one vague trust statement.
Modern controls are used to justify delayed boundary hardening.

The anti-pattern is familiar: improved mechanism, unchanged consequence.

A Decision Filter for Design Reviews

Use this filter when reviewing managed identity or federation adoption:

What credential-handling risk was removed, specifically?
What authorization consequence remains unchanged?
Which trust assumptions are now external dependencies, and how are they bounded internally?
Under compromise of a valid token, what exact boundary still holds?

If the team can answer the first question but not the last two, modernization is incomplete.

Real-World Impact

This distinction directly affects the quality of both design and governance decisions.

Strategy alignment

Leaders avoid false confidence when mechanism and boundary outcomes are reported separately. That clarity prevents premature closure of identity risk programs.

Engineering execution

Teams make better backlog decisions when they treat boundary hardening as part of identity modernization rather than a later phase. Security debt reduces faster when both tracks run together.

Incident resilience

Response plans become more credible when federated and managed identity controls are tied to explicit containment boundaries. Otherwise incident teams still discover real limits during live pressure.

Governance maturity

Governance improves when architecture owners are accountable for trust consequence, not only identity mechanism rollout. This shifts accountability from deployment completion to risk outcome.

Gotchas and Edge Cases

These are common reasons technically correct modernization still underperforms.

Federation can be reliable and still over-permissive

A stable external issuer does not guarantee safe internal authorization. Strong claim integrity with weak scope controls still produces broad blast radius.

Managed identity can hide privilege accumulation

Because managed identities feel “safe,” teams may grant broad access faster and review it less often. Operational trust in the mechanism can reduce rigor in scope governance.

Mixed models increase ambiguity

Environments with partial federation, partial managed identity, and legacy secret-based services often create unclear accountability boundaries. Review complexity rises while confidence drops.

Control ownership can fragment

Identity platform teams may own issuance controls while workload teams own authorization scope. Without a shared review model, risks move between teams without being resolved.

Best Practices

Report mechanism gains and boundary gains separately

State exactly what was improved in credential handling and exactly what was improved in containment. Keep these as two explicit score lines.

For federated identities, document delegated versus retained controls

Write down what external systems must guarantee and what Azure authorization boundaries must still enforce internally.

Tie modernization milestones to boundary revalidation

Do not complete identity modernization until effective scope and transitive reachability have been reassessed and reduced where needed.

Assign one owner for residual trust-graph risk

If mechanism and boundary ownership are split, designate a single accountable owner for consequence under compromise.

🍺

Brewed Insight: Managed identity and federation modernize trust transport, not trust consequence. Moving off secrets is real progress - but if boundary design doesn’t change alongside it, the shape of the risk hasn’t changed nearly enough.

Learn More

How Workload Identity Fails: The Compromise Paths You Build by Design

Thu, 13 Aug 2026 00:00:00 +1000

Most post-incident identity reviews still ask the wrong question first.

They ask how the attacker got valid access.

In mature Azure estates, that is often the easiest part of the story to explain. The harder part is what that access could already reach once it was valid.

That reach is usually designed, not discovered.

The Mental Model

Workload identity failure is not one broken control. It is a path problem across trust edges that were individually rational but collectively dangerous.

An identity compromise becomes material when it can traverse multiple control planes with legitimate permissions:

Identity plane: token issuance and accepted trust relationships
Management plane: role assignments and inherited administrative reach
Data plane: service-to-service access where business workloads actually live

Attack paths in workload identity are architectural sequences, not authentication events.

This is why teams miss them. They validate controls in isolation and never validate consequence in combination.

How It Actually Works

Three path patterns create most of the real exposure.

Privilege layering without boundary intent

Identities are granted access over time by different teams solving different delivery needs. The resulting permission set looks reasonable in each sprint but excessive across the whole path. When compromise occurs, the attacker benefits from years of cumulative convenience.

Service-mediated pivoting

A workload identity might only have moderate direct permissions. But if it can invoke an automation service, deployment pipeline, or orchestration account with broader rights, compromise escalates through service relationships rather than direct role elevation.

Inheritance-driven expansion

Assignments at broad scopes make future resources reachable by default. Identity risk then grows automatically with platform growth, even when no one touches the identity again.

flowchart TD A[Compromised workload identity] --> B{Direct permissions limited?} B -->|Yes| C[Invoke trusted service dependency] B -->|No| D[Immediate broad reach] C --> E{Dependency has elevated scope?} E -->|Yes| F[Transitive privilege expansion] E -->|No| G[Localized impact] D --> H[Cross-resource compromise path] F --> H G --> I[Containment possible] H --> J[Systemic exposure event]

The important point is not that these paths exist. It is that they remain predictable once you model identity relationships as a graph instead of isolated controls.

When This Pattern Reduces Risk and When It Increases It

Reduces risk when

Identity scope and dependency edges are reviewed together, not in separate governance streams.
High-privilege automation services are isolated from routine workload identities.
Broad-scope assignments have owner, purpose, and expiry.
Architecture reviews test path consequence, not control presence.

Increases risk when

Teams assume managed identity use implies path safety.
Service dependencies are trusted by default because they are “internal”.
Role inheritance is treated as administrative convenience instead of attack surface.
Review artifacts list permissions but do not model traversal.

The recurring failure mode is simple: local optimization creates global reachability.

A Decision Filter for Design Reviews

If you want to test a workload identity design quickly, pressure-test these questions:

Which services can this identity call that can act with broader authority?
Which assignments are inherited and therefore expanding as the estate grows?
What is the shortest path from this identity to a business-critical control function?
Which path edge would break containment first under compromise?

If the team cannot answer without reverse-engineering the environment, the design is under-modeled.

Real-World Impact

These path failures matter because they convert routine delivery patterns into high-consequence incident pathways.

Incident handling quality

Response quality drops when teams only understand direct permissions and discover transitive dependencies during the incident. The first hour becomes architecture archaeology rather than containment action.

Architecture decision quality

Design decisions become better when identity boundaries are evaluated as path constraints. Teams stop over-valuing local delivery speed and start valuing path determinism under compromise.

Risk reporting quality

Risk reporting gets sharper when findings are written as traversal consequence instead of control inventory. Leaders can prioritize containment work when they can see path length, pivot points, and likely impact domains.

Platform evolution safety

As estates evolve, path-aware identity design prevents silent exposure growth. Without that discipline, each new service can inherit old trust assumptions and widen compromise potential by default.

Gotchas and Edge Cases

These are the patterns that repeatedly create false confidence in otherwise well-built environments.

Low direct privilege can still be high consequence

A workload identity with limited direct rights may still invoke a trusted service with elevated authority. Direct scope looks safe while transitive scope remains dangerous.

Internal service trust is often over-generalized

Teams frequently assume internal services are safe pivots because they are platform-managed. Internal origin does not remove the need for boundary design and constrained invocation rights.

Inheritance is easy to forget and hard to debug

Inherited assignments are not always visible in local design artifacts. During incidents, this creates disagreement about intended versus effective reach and delays decisive containment.

Path controls decay through operational shortcuts

Temporary exceptions added during release pressure often become permanent path edges. The accumulated effect is broader traversal than the architecture originally allowed.

Best Practices

Model identity as traversable paths

Document not just “what this identity can access” but “what this identity can trigger that can access more.” That second statement usually reveals real exposure.

Separate routine workload identities from control-plane orchestrators

If an identity can both run business workload actions and influence control-plane automation, blast radius is already too broad.

Review inherited scope on every architecture change

Treat inheritance as a changing risk surface, not a static baseline. New resources can create new consequences without new assignments.

Write findings as consequence chains

Use language like “identity A can invoke service B which can modify C”. This produces better remediation decisions than abstract permission lists.

🍺

Brewed Insight: Workload identity compromise turns severe when the architecture lets authority travel farther than anyone intended. Control quality matters, but it’s the geometry of the path - what connects to what - that decides the actual consequence.

Learn More

Workload Identity Is a Trust Graph, Not a Credential Problem

Tue, 11 Aug 2026 00:00:00 +1000

Most teams celebrate when they remove secrets from workloads.

They should. It is a real security improvement.

It is also where many identity architectures become dangerously self-congratulatory.

If your design review ends at “we use managed identity now,” you did credential hygiene, not identity architecture.

The Mental Model

Workload identity security is usually discussed as an authentication problem. That framing is too narrow for serious environments.

Authentication answers whether a principal is valid. Architecture answers what that principal can reach once valid.

That distinction is the whole argument.

Secret removal reduces credential theft risk. Trust graph design determines compromise consequence.

A workload identity model should be read as a graph:

Nodes: managed identities, service principals, federated subjects, automation identities.
Edges: role assignments, delegated permissions, cross-service access grants, trust to external token issuers.
Consequence: blast radius produced by transitive reachability, not by credential format.

If a compromised identity can still traverse high-value services through legitimate permissions, the architecture is weak even when secret hygiene is excellent.

How It Actually Works

In practice, identity exposure grows through three repeatable patterns.

Inherited scope drift

Assignments at management group, subscription, or broad resource group scope create reachability that local teams do not always notice. The identity keeps becoming more useful operationally and more dangerous architecturally.

Shared identity surfaces

When multiple workloads share one identity for convenience, one compromise becomes multi-workload access. That is not an incident surprise. It is a design outcome.

Transitive access chains

A workload identity often cannot reach crown-jewel data directly, but it can reach a service that can. These second-order edges are where many threat models stay shallow.

flowchart TD A[Compromised workload identity] --> B{Effective scope boundary} B -->|Narrow, workload-local| C[Local containment] B -->|Broad RG/Subscription| D[Cross-resource reachability] D --> E{Transitive service edges present?} E -->|No| F[Elevated but bounded impact] E -->|Yes| G[Pivot path across trust zones] G --> H[Systemic exposure event] C --> I[Periodic boundary review] F --> I H --> J[Architecture redesign required]

The practical point is blunt: compromise impact is mostly pre-decided by scope topology before any attacker arrives.

Where Teams Misjudge Managed Identity and Federation

Managed identity and federation are both useful. Neither is a substitute for trust boundary design.

Managed identity: what it solves and what it does not

Managed identity materially improves:

Secret handling and storage risk
Rotation burden and stale credential drift
Human exposure to credential material

Managed identity does not materially improve by itself:

Permission scope quality
Transitive privilege chains
Blast radius of inherited role assignments

Treating managed identity rollout as completion criteria is architectural shallowness.

Federation: delegated trust boundaries must be explicit

Federation needs tighter language than “it depends on the external issuer.” That is directionally true but incomplete.

When a workload identity trusts an external issuer, security responsibility splits:

Delegated to external issuer:
- Subject integrity (who the token claims to represent)
- Claim issuance controls
- Upstream identity assurance process
Retained in Azure/control plane design:
- Which issuer/audience combinations are accepted
- Which resources and roles the federated identity can reach
- How far privilege propagates after successful token exchange

So the architecture question is not “is federation secure?” It is:

Have we constrained federated trust so a valid external claim cannot become broad internal reachability?

Without that boundary precision, federation discussions become hand-waving and reviewers rightly push back.

When This Pattern Reduces Risk and When It Increases It

Reduces risk when

Identity scope is intentionally narrow and regularly revalidated.
Shared identities are exceptional rather than default.
Cross-service grants are explicit, justified, and reviewed as architectural exceptions.
Federated trust accepts only tightly bounded issuer/audience/subject combinations.

Increases risk when

Broad scope is justified with “delivery speed” and never revisited.
Automation identities accumulate permissions release by release.
External federation is introduced without a clear internal blast-radius boundary.
Design reviews discuss identity mechanism but not effective reachability.

The anti-pattern is common and predictable: teams modernize credentials while preserving legacy trust sprawl.

A Decision Filter for Design Reviews

If this article is useful, it should change review behavior immediately.

Use this filter in architecture reviews:

What is the maximum effective reach of this identity today, including inherited assignments?
Which transitive edges can this identity exploit indirectly through other services?
For federated identities, which controls are external dependencies versus internal design controls?
If this identity is compromised now, where does containment actually stop?

If these questions cannot be answered quickly from current evidence, the design is operating on assumed trust, not controlled trust.

Real-World Impact

This only matters if it changes decisions in live environments, not just language in architecture decks.

Design quality

Strong teams stop treating workload identity as a provisioning task and start treating it as a boundary design discipline. The review standard shifts from “did we remove secrets” to “can we prove where compromise stops.” That change makes architecture reviews harder, but materially better.

Reliability under pressure

Containment speed in incidents is mostly determined before the incident starts. When identity boundaries and transitive edges are explicit, responders can isolate quickly without reconstructing trust logic from scratch. When they are implicit, outage and containment timelines both expand.

Security governance

Governance quality improves when drift review is tied to reachability change rather than policy inventory. Counting identities tells you very little; understanding effective scope and inheritance tells you where risk is accumulating. That is the difference between administrative control and architectural control.

Scalability

Scale is not “how many identities we can create.” Scale is whether teams can reason about compromise consequence without escalation to a few platform specialists. If only a small group can explain trust boundaries, the architecture has not scaled, even if automation has.

Gotchas and Edge Cases

These are the conditions that repeatedly make otherwise good identity designs fail in production.

Least-privilege intent can still produce broad effective reach

Teams often document narrowly scoped intent while inherited role assignments quietly widen the operational boundary. The design looks controlled in documentation but behaves broadly in practice. Always validate effective scope, not intended scope.

Shared platform identities hide concentrated failure domains

One identity serving multiple workloads reduces operational overhead and increases correlated risk at the same time. During compromise, those workloads collapse into a single incident boundary whether teams planned for that or not. Shared identity should be an explicit exception with ownership.

Federation reliability can mask federation over-trust

A stable external issuer does not guarantee a safe internal trust boundary. External claim integrity and internal authorization scope are separate control planes and must be reviewed separately. Good issuer hygiene cannot compensate for over-broad internal role design.

Drift accumulates through reasonable exceptions

Most exposure growth is gradual and justified one change at a time. No single change looks dangerous, but the aggregate trust graph becomes harder to contain. This is why periodic architecture-level identity review must be mandatory rather than optional.

Best Practices

Review identity as a graph, not a setting

Evaluate nodes, edges, and transitive reachability together. Single-control reviews miss system behavior.

Separate external assurance from internal authorization

For federated identities, document what is trusted externally and what is constrained internally. Do not blend the two in one vague control statement.

Treat broad scope as debt with an owner and expiry

If broad grants are temporarily necessary, assign ownership and expiry criteria. Scope without expiry is silent risk growth.

Make one question mandatory in every identity review

Before approval, require this answer in writing:

What is the smallest boundary where compromise of this identity is guaranteed to stop, and what evidence proves it?

🍺

Brewed Insight: If your workload identity review can prove who can authenticate but can’t prove where a compromise stops, the design is still immature - no matter how modern the credential mechanism looks on paper.

Learn More

Exposure-Driven Architecture Reviews

Thu, 06 Aug 2026 00:00:00 +1000

Most security architecture reviews produce long findings lists and limited strategic change.

They prove controls exist, but they often fail to prove exposure is constrained.

An exposure-driven review changes that by starting from adversarial consequence logic: what can be reached, how far authority can propagate, where containment fails, and which assets make that failure material. This approach is not a replacement for governance controls; it is the architectural layer that makes those controls decision-relevant.

The Mental Model

Exposure-driven review is a synthesis exercise across trust, path, containment, and criticality.

Instead of beginning with standards conformance, it begins with four architecture questions:

Reachability: Which compromise paths are actually traversable?
Propagation: How can authority expand across identity, management, and service dependencies?
Containment: Where is compromise guaranteed to stop?
Materiality: Which reachable assets make consequence business-significant?

This model reframes review outputs from “control status” to “consequence logic.” For senior stakeholders, that shift is essential because strategic choices require understanding trade-offs in exposure, not just compliance posture.

In Azure-hosted estates, where shared responsibility spans platform, workload, and governance teams, exposure-driven reviews also create a common language for cross-layer decisions.

Review output quality bar

A review should be considered decision-ready only when every major finding includes:

A reachable path statement (starting point, pivot edge, impacted asset).
A propagation mechanism across identity, management, or service dependency planes.
A containment boundary statement describing where the sequence must stop.
A trade-off statement describing cost, delivery friction, and residual risk if accepted.

Without these four elements, review outputs drift back into issue lists that look complete but do not support executive decisions under pressure.

If a finding cannot be expressed as a consequence chain with boundary logic, it should not drive architecture priority.

How It Really Works

A strong exposure review assembles evidence into coherent risk chains rather than independent issue statements.

Integrate prior architecture lenses

The review should combine combinational control behavior, attack path mapping, choke-point quality, blast-radius boundaries, and critical asset significance into one model. Treating these as separate workstreams fragments decision quality.

Distinguish theoretical weakness from reachable consequence

Not every weakness is materially exposed. Review quality improves when findings explicitly show reachable path conditions and required assumptions. This prevents over-prioritization of low-consequence issues and under-prioritization of path-enabling design flaws.

Express decisions as trade-offs

Exposure rarely reduces without operational cost. Reviews should surface trade-offs clearly: where control concentration may increase dependency risk, where isolation may reduce delivery flexibility, and where governance strictness may affect platform velocity.

flowchart TD A[Architecture evidence inputs] --> B[Trust and dependency mapping] B --> C[Reachability/path analysis] C --> D[Containment boundary validation] D --> E[Critical asset consequence overlay] E --> F{Material exposure proven?} F -->|No| G[Monitor and defer] F -->|Yes| H[Decision trade-off framing] H --> I[Prioritized architectural actions]

The output should be an architecture decision set that leadership and engineering can execute, not an issue register that accumulates without structural change.

Real-World Impact

Exposure-driven reviews matter because they improve both strategic alignment and operational resilience.

Higher-quality remediation decisions

By linking weaknesses to reachable consequence and critical asset impact, teams prioritize architecture actions that reduce systemic risk instead of chasing high-volume low-impact findings.

Faster cross-functional alignment

Platform, identity, security, and product teams can align more quickly when review outputs are framed as shared consequence paths. This reduces prolonged debate over control ownership and accelerates boundary-focused improvements.

More defensible governance outcomes

Governance improves when control exceptions are evaluated for exposure consequence, not just policy variance. Leaders can approve, reject, or time-bound exceptions with clearer understanding of system-level impact.

Increased incident preparedness

Because exposure-driven reviews model propagation and containment explicitly, incident teams inherit a better operational map during crises. Decision time shortens and response confidence increases.

Gotchas and Edge Cases

Exposure-oriented methods are powerful, but they can fail if execution drifts back into familiar checklist habits.

Over-collection of evidence without synthesis

Teams can gather extensive logs, diagrams, and control metadata yet still miss key exposure logic if evidence is not assembled into traversable consequence chains.

Path analysis without criticality context

A technically valid path may not be materially significant, while a shorter path to a control anchor may be existential. Review outputs must combine path feasibility with asset consequence, not treat them separately.

Binary scoring hides trade-offs

Pass/fail summaries are easy to report but weak for architecture decisions. Exposure review requires graded reasoning about uncertainty, consequence, and design cost.

Recommendations can become implementation checklists

Review quality degrades when outputs prescribe product-level configuration steps rather than architectural intent and boundary outcomes. Keep findings at the system decision level unless technical depth is explicitly needed.

Best Practices

Anchor every finding to consequence logic

Each finding should explain path, propagation mechanism, boundary failure point, and impacted critical assets. If any element is missing, the recommendation is probably not decision-ready.

Use explicit confidence and assumption statements

Where data is incomplete, document assumptions and confidence levels. This prevents false certainty and helps teams target evidence collection efficiently.

Separate immediate controls from structural redesign

Short-term controls can reduce current exposure, but long-term risk often requires architecture change. Make both layers explicit so tactical fixes do not displace strategic remediation.

Maintain a recurring exposure review cadence

Cloud architecture changes continuously. Exposure review should be periodic and event-driven, triggered by major platform, identity, or governance shifts that alter trust and dependency geometry.

🍺

Brewed Insight: A review is only defensible when it can explain why a weakness matters, how compromise propagates, where containment fails, and which assets make the outcome material - a long findings list without that context tells you controls existed, not whether exposure ever actually stopped.

Learn More

Critical Asset Mapping

Tue, 04 Aug 2026 00:00:00 +1000

Many organizations say everything is critical, then struggle to defend anything effectively.

That is not a policy problem. It is an architecture prioritization problem.

Defensive architecture requires choosing where to concentrate protection effort based on systemic consequence, not broad importance labels. Critical asset mapping provides that discipline by identifying which assets control trust decisions, enable recovery, and materially determine business survivability when compromised.

The Mental Model

A critical asset is not simply a valuable data store or visible production service.

An asset is critical when compromise of that asset can disproportionately alter authority, availability, or trust for many other systems. In other words, criticality is a function of transitive influence, not local significance.

A useful way to classify assets for defensive architecture is:

Control assets: identity authorities, policy engines, key management, deployment control functions.
Consequence multipliers: services whose compromise exposes many downstream systems.
Operational continuity anchors: systems required to recover safely from disruption.
Business value concentration points: high-impact data and services tied directly to survivability outcomes.

This framing avoids a common trap: ranking assets only by confidentiality sensitivity while ignoring assets that can reshape trust boundaries and control posture.

Criticality proof test

An asset should be treated as tier-one critical only when at least one of the following is true:

Compromise can alter identity, policy, key, or deployment authority for multiple domains.
Compromise can disable or degrade recovery for multiple business services.
Compromise can expose or influence data with cross-domain business consequence.
Compromise can materially expand attacker reach through transitive dependencies.

This test should be re-run whenever inheritance scope, automation pathways, or platform dependencies change.

If a criticality model cannot explain transitive consequence, it is an inventory label, not an architecture decision tool.

How It Really Works

Critical asset maps become meaningful when built from dependency logic rather than ownership charts.

Start with control significance, not visibility

Highly visible customer workloads are often treated as most critical by default, while quieter control assets receive less scrutiny. In many incidents, compromise of a control asset creates broader consequence than compromise of a single customer-facing workload.

Trace transitive dependence across platform layers

If service A depends on identity authority B, key management C, and deployment control D, then B, C, and D may be more critical from a systemic risk perspective than A itself. Mapping transitive dependencies reveals this hidden hierarchy.

Tie criticality to path and containment context

Criticality should not be assessed in isolation. An asset that is inherently important but strongly isolated may represent lower immediate architecture risk than a moderately important asset that is broadly reachable through weakly constrained trust edges.

flowchart LR A[Business service] --> B[Identity authority] A --> C[Key management] A --> D[Deployment control] D --> E[Policy/config influence] B --> F[Privilege propagation potential] C --> G[Data access unlock potential] E --> H[Environment-wide consequence] F --> H G --> H

The point is not to produce a perfect map. It is to reveal which assets shape system-wide consequence so defensive investment aligns with real architectural risk.

Real-World Impact

Critical asset mapping improves security outcomes by making prioritization explicit, defensible, and architecture-driven.

Better allocation of defensive effort

Teams can direct engineering and governance attention toward assets that determine broad trust outcomes, rather than spreading effort evenly across long asset inventories. This increases risk reduction per unit of effort.

Sharper incident planning and containment

When critical control assets are known and protected as consequence multipliers, incident response can prioritize preserving or restoring those anchors first, reducing cascading impact across dependent services.

Higher quality executive risk communication

Leaders can evaluate trade-offs more effectively when criticality is explained as systemic influence and business consequence. This is more actionable than abstract severity labels or tool-generated score aggregates.

Stronger change management discipline

Architecture changes affecting critical assets can be reviewed with heightened rigor because teams understand downstream consequence. This reduces accidental trust-boundary erosion during normal delivery cycles.

Gotchas and Edge Cases

Criticality work is often undermined by assumptions that seem reasonable but produce weak defensive priorities.

High usage is not the same as high consequence

Frequently accessed assets are not always the most critical. Low-traffic control functions can carry much higher systemic consequence because they govern authority for many services.

Data sensitivity labels can distort priorities

Classification frameworks are useful, but they can over-emphasize storage assets and under-emphasize control-plane assets that can indirectly expose or alter those stores.

Criticality can drift as dependencies evolve

Asset importance is dynamic. New automation pathways, role inheritance changes, and platform integrations can elevate previously moderate assets into high-consequence positions.

Ownership boundaries can hide shared consequence

Asset owners may optimize local risk while missing transitive impact on other domains. Critical mapping must cross organizational boundaries to reflect true architectural influence.

Best Practices

Define criticality using consequence logic

Ask which assets can change trust, privilege, or recovery outcomes for multiple domains. Use this as the primary criterion before adding business or compliance overlays.

Maintain a dependency-aware critical map

Update critical asset views whenever major identity, platform, or governance changes occur. Static annual assessments are too slow for cloud-scale dependency drift.

Link critical assets to containment strategy

For each critical asset, define the minimum boundary where compromise must be contained and the controls that guarantee that boundary under pressure.

Prioritize protection of control and recovery anchors

Assets that govern identity, policy, key material, and recovery should be treated as strategic defensive priorities even when they are not highly visible to business stakeholders.

🍺

Brewed Insight: Critical assets are the systems that decide what else can fail. If your priority model can’t explain transitive consequence - why compromising this backup vault or that admin group matters more than the flashier workload next to it - it’s an inventory label, not a defensive architecture model.

Learn More

Designing Blast Radius

Thu, 30 Jul 2026 00:00:00 +1000

Containment is often discussed as if it starts during incident response.

In reality, containment starts during architecture decisions long before any incident occurs.

Blast radius reflects how far authority, trust, and dependency can propagate after a compromise event. If those propagation paths are broad, incident teams do not “choose” a small blast radius in the moment. They inherit the one the architecture already created.

The Mental Model

Blast radius is a design property of reachable consequence, not a post-incident metric.

To reason about blast radius in Azure-hosted environments, treat compromise as a propagation problem across five dimensions:

Identity scope: what principals can reach through direct and inherited access.
Administrative scope: how management-plane rights can alter controls and resources.
Service coupling: where shared dependencies can spread operational and security impact.
Data concentration: where high-value assets create consequence multipliers.
Recovery authority: which emergency pathways can override normal boundaries.

This model prevents the common mistake of equating segmentation presence with containment quality. Segments can exist on paper while privilege inheritance and service dependencies still allow practical cross-boundary movement.

Containment confidence test

Containment design is credible only when teams can answer these questions before deployment:

Which identities can cross subscription or environment boundaries through inherited administrative scope.
Which shared control services (identity, key management, deployment automation, networking) can create cross-domain consequence if compromised.
Which recovery channels can bypass normal segmentation and how quickly those channels can be revoked.
Which boundary is the first guaranteed stop point for compromise propagation across identity, management, and data planes.

If containment depends on responders discovering boundaries during an incident, blast radius was never designed.

How It Really Works

Blast radius expansion is usually a byproduct of efficiency optimizations.

Shared platforms and inherited trust

Shared platform services reduce cost and operational friction, but they also increase trust transitivity. When multiple domains depend on common control services, one compromise can influence many workloads indirectly.

Broad administrative inheritance

Management group and subscription-level delegation can speed delivery but enlarge consequence domains. A principal compromise in one team context can alter security posture in unrelated environments if administrative inheritance is not tightly bounded.

Recovery channels as latent expansion paths

Break-glass accounts, emergency network routes, and broad restoration privileges are necessary for resilience. They are also high-consequence authority channels. If poorly constrained, they can expand blast radius during exactly the periods when decision pressure is highest.

flowchart TD A[Compromise event] --> B{Identity boundary narrow?} B -->|Yes| C[Local scope pressure] B -->|No| D[Cross-domain identity reach] C --> E{Shared services tightly isolated?} D --> F[Administrative inheritance expansion] E -->|Yes| G[Contained consequence] E -->|No| H[Service-coupled spread] F --> H H --> I{Recovery channels constrained?} I -->|Yes| J[Managed containment recovery] I -->|No| K[Systemic blast radius]

The objective is not zero spread under all conditions. The objective is deterministic boundaries that keep compromise consequence proportionate and recoverable.

Real-World Impact

Blast radius design quality directly shapes business impact, recovery speed, and leadership confidence during incidents.

Incident consequence control

Architectures with explicit containment boundaries produce smaller, more predictable incident scopes. Teams can isolate affected domains without shutting down unrelated services or introducing broad emergency privileges.

Recovery confidence

When containment boundaries are designed and tested as architectural properties, recovery plans rely less on improvisation. Operational teams know which controls can be trusted during disruption and where authority remains bounded.

Investment prioritization

Blast-radius analysis improves prioritization by identifying where shared dependencies and inherited privileges create disproportionate consequence. This enables targeted investment in isolation and mediation rather than broad, low-yield hardening.

Governance quality

Governance becomes more useful when it tracks consequence boundaries and boundary drift. Counting controls is not enough; organizations need evidence that compromise spread remains constrained as the platform evolves.

Gotchas and Edge Cases

Containment design fails most often when organizations confuse isolation visuals with true authority boundaries.

Segmentation can look strong and behave weakly

Network segmentation does not guarantee containment if identities can still invoke control-plane operations or trusted automation across segments. Effective blast radius depends on combined identity and management boundaries.

Shared control services can silently expand risk

Centralized logging, key management, automation, and CI/CD platforms are operationally valuable. If privilege boundaries around these services are broad, they become compromise multipliers rather than stabilizers.

Emergency access can become permanent posture

Access patterns introduced during outages or migrations often persist long after the triggering event. Unexpired emergency pathways are a common source of unexpected consequence expansion.

Boundary intent decays during platform growth

As subscriptions, workloads, and teams scale, initially clear boundary intent can drift through inheritance and convenience-based exceptions. Without periodic architecture review, blast radius grows without explicit approval.

Best Practices

Define containment boundaries in architectural terms

State where compromise must stop across identity, administration, and service dependency layers. Make this a design requirement, not an incident objective.

Treat broad inheritance as explicit risk debt

If broad scopes are operationally unavoidable, assign ownership, review cadence, and measurable exit criteria. Containment debt without accountability becomes structural exposure.

Isolate high-consequence shared services

Platform services that can influence many domains should have stricter mediation, stronger identity controls, and narrower administrative pathways than ordinary workloads.

Review recovery pathways with adversarial assumptions

Resilience mechanisms should be tested for misuse potential as rigorously as for availability outcomes. A recovery path that defeats containment is a security-critical design flaw.

🍺

Brewed Insight: Blast radius is never what your architecture diagrams imply. It’s what a compromised identity or control-plane principal can actually still reach once the assumptions behind that diagram stop holding.

Learn More

Designing Choke Points

Tue, 28 Jul 2026 00:00:00 +1000

Good architecture does not try to inspect every possible interaction equally.

It deliberately creates places where high-consequence interactions must pass through constrained decision points.

Those points are choke points: boundaries where trust extension is mediated, logging is meaningful, and bypasses are intentionally difficult. In enterprise cloud environments, choke points are one of the few scalable ways to move from reactive security operations toward deterministic defensive architecture.

The Mental Model

A choke point is not a product. It is a design property of path concentration with controllable friction.

In defensive terms, a choke point is valuable when it does three things simultaneously:

Concentrates multiple risky paths into fewer decision locations.
Constrains authority with policy, identity, and network checks before trust propagates.
Clarifies accountability because control ownership and consequence boundaries become explicit.

This model is especially relevant in Azure-hosted estates where identity relationships, management-plane actions, and service dependencies can multiply quickly. Without intentional choke design, environments drift toward distributed trust where no single team can confidently explain where compromise should stop.

The trade-off is real: concentration can improve control quality but also create critical dependencies. Designing choke points is therefore a balancing act between resistance, resilience, and operational flow.

Choke-point readiness criteria

A boundary should not be labeled a choke point unless it meets all of the following:

Mandatory traversal: high-consequence identity and management actions cannot bypass the boundary through alternate service links, delegated admin paths, or emergency channels.
Layered mediation: identity context, policy evaluation, and network decision controls are all enforced at the same boundary transition.
Failure-safe behavior: degraded operation defaults to constrained access with auditable escalation, not broad operational override.
Bypass governance: every exception has expiry, owner, and explicit blast-radius consequence documented at review time.

A boundary that is easy to bypass during outages is an observation point, not a choke point.

How It Really Works

Effective choke point design is about architecture geometry, not just policy enforcement.

Path convergence before privilege expansion

The most useful choke points sit where low-trust interactions transition into higher authority domains. Examples include privileged administration pathways, outbound dependency mediation, and cross-segment service invocation boundaries. The key is to mediate before privilege multiplies, not after.

Decision quality and bypass resistance

A nominal choke point that can be bypassed by alternate identity paths, direct service links, or emergency access shortcuts is not a choke point in practice. Real choke design requires periodic validation that alternate routes remain constrained or explicitly governed.

Coupling awareness and failure behavior

Because choke points often centralize control decisions, they can also centralize failure modes. If availability design is weak, teams may introduce broad override paths during outages, silently removing the very mediation the choke point was intended to provide.

flowchart TD A[Low-trust request path] --> B{Must cross mediated boundary?} B -->|No| C[Bypass route exists] C --> D[Nominal choke point only] B -->|Yes| E[Policy + identity + context checks] E --> F{Decision outcome} F -->|Allow| G[Constrained authority extension] F -->|Deny| H[Containment preserved] G --> I{Operational override available?} I -->|Uncontrolled| D I -->|Governed| J[Resilient choke design]

This is why choke points must be designed as a control system with explicit resilience behavior, not a static rule location.

Real-World Impact

Choke points matter because they shape whether compromise scales or stalls.

Reduced attacker optionality

When critical paths converge through mediated boundaries, attackers face fewer low-friction routes to privilege expansion. Compromise efforts become noisier and more detectable, increasing defender decision time.

Higher-fidelity security telemetry

Concentrated decision points produce more meaningful telemetry than broad, distributed controls. Signals are closer to high-consequence trust transitions, improving detection relevance and investigative speed.

Stronger governance accountability

Choke points force ownership clarity. Teams can no longer rely on vague “shared responsibility” language when explicit boundaries define who controls access mediation and who accepts associated risk.

Better architecture change control

As environments evolve, choke point placement provides a stable framework for evaluating proposed changes. Teams can ask whether a change preserves mediation, introduces bypasses, or weakens control independence.

Gotchas and Edge Cases

Most choke point failures come from design shortcuts made in the name of convenience or resiliency.

Centralization without resilience planning

A choke point that becomes a brittle single dependency will eventually trigger pressure for bypass channels. Without resilient operating design, reliability incidents can directly degrade security posture.

Policy concentration without identity concentration control

Teams may centralize policy evaluation while allowing identity sprawl and broad delegated administration around the boundary. This creates the appearance of control while maintaining real traversal flexibility.

Hidden alternate routes through trusted services

Service integrations and automation pathways often bypass intended chokepoints when they are classified as internal operational flows. These routes must be modeled and constrained as rigorously as external paths.

Exception handling that outlives emergency conditions

Temporary elevated access channels are often created under legitimate urgency. If expiry and rollback are weak, emergency paths become steady-state bypasses.

Best Practices

Design choke points where consequence is decided

Prioritize boundaries where privilege expansion, data concentration access, or control-plane modification becomes possible. Do not waste choke complexity on low-consequence interactions.

Validate bypass resistance continuously

Treat alternate route discovery as a recurring architecture activity. A choke point is only as strong as the weakest reachable path around it.

Pair security mediation with resilient operations

Engineer availability, failover, and observability into choke point designs so operational incidents do not force broad manual overrides.

Govern exceptions as boundary alterations

Require owner, expiry, and consequence analysis for every choke-point exception. Record each exception as an architectural trust edit, not as routine ticket metadata.

🍺

Brewed Insight: A choke point only earns its keep when it stays the easiest path for legitimate operations and the hardest path to bypass under pressure - the moment engineers start routing around it to hit a deadline, it’s stopped doing its job.

Learn More

Understanding Azure Attack Paths

Thu, 23 Jul 2026 00:00:00 +1000

Most architecture reviews describe controls by domain: identity, network, compute, data, operations.

Attackers do not operate by domain. They operate by reachability.

That difference is why many well-governed environments remain surprisingly exposed. A control can be correct in its local domain while still enabling traversal when combined with upstream trust edges and downstream service relationships. Path-based reasoning closes that gap by asking a harder question: not “is this configured properly,” but “what can be reached from here if compromise occurs now.”

The Mental Model

An attack path is an architectural sequence of reachable decisions, not a list of vulnerabilities.

In Azure environments, this sequence often traverses three interconnected planes:

Identity plane: token issuance, authentication trust, directory and principal relationships.
Management plane: role assignments, resource governance, configuration authority.
Data plane: workload-level service access, runtime actions, and business data operations.

A weakness in one plane only becomes material if it links to meaningful authority in another. Defensive architecture therefore treats attack paths as graph logic: nodes, edges, constraints, and consequence.

This model changes design priorities. Instead of optimizing each control for local correctness, teams optimize for path disruption: where to break traversal, where to force mediation, and where to guarantee containment.

Path-confidence decision test

Architecture teams should treat a path model as incomplete until it answers these four questions with concrete evidence:

Which role assignments are inherited from management group, subscription, or resource group scope, and how that inheritance changes reachability.
Which identities can influence policy, deployment templates, key material, or network routing through management-plane actions.
Which service dependencies can be invoked to gain transitive authority beyond direct permissions.
Which single edge removal would most reduce compromise consequence, and whether that edge is currently governed.

If a path analysis cannot identify its highest-consequence pivot edge, it is documentation, not defensive architecture.

How It Really Works

In practice, path formation is usually the result of normal delivery decisions, not obvious misconfiguration.

Identity edges that over-trust reachability

Broad role assignment inheritance, shared automation identities, and permissive service principals create identity edges that are operationally convenient but architecturally expansive. A foothold that should stay local can gain cross-scope influence through valid but over-broad identity relationships.

Management-plane authority as a pivot layer

Management plane privileges often have more systemic consequence than data plane privileges. If a compromised identity can modify policy assignments, network controls, deployment templates, or key management settings, it can reshape the environment to unlock new paths.

Data-plane adjacency and service dependency chains

Many paths do not require direct access to crown-jewel assets. They require access to services that can influence those assets. Queue processors, orchestration workflows, and platform-managed integrations can become path amplifiers when trust boundaries are implicit.

flowchart LR A[Initial foothold in workload] --> B{Identity edge available?} B -->|No| C[Local impact] B -->|Yes| D[Role/Principal expansion] D --> E{Management-plane action possible?} E -->|No| F[Data-plane constrained path] E -->|Yes| G[Policy/Config influence] G --> H{Can controls be weakened or bypassed?} H -->|No| I[Limited pivot] H -->|Yes| J[New traversal routes opened] J --> K[Critical asset reachable]

Path analysis is useful precisely because it reveals how local trust decisions become global consequence chains.

Real-World Impact

Path-first review improves architecture decisions by exposing reachable consequence instead of relying on control inventories.

Better prioritization of security work

Without path context, teams prioritize visible issues rather than consequential ones. With path context, engineering effort shifts toward breaking high-impact traversal edges, reducing inherited authority, and hardening pivot services that determine systemic risk.

Faster incident containment

When path maps are part of architecture practice, responders know likely pivot routes before an incident. Containment actions become directed and time-bounded rather than exploratory and reactive.

Stronger cross-team coordination

Path-based models create a shared language across platform, identity, network, and application teams. Instead of arguing over control ownership, teams can collaborate on sequence interruption and containment assurance.

More defensible leadership decisions

Executives and technical decision makers gain clearer risk narratives when findings are expressed as “reachable consequence” rather than as disconnected policy deviations. That clarity supports better trade-off decisions under budget and time constraints.

Gotchas and Edge Cases

Attack path work is high value, but teams repeatedly undercut it with predictable mistakes.

Static diagrams age quickly in dynamic estates

Cloud environments evolve faster than static path diagrams. If path reasoning is performed once per project rather than continuously at architecture checkpoints, critical traversal edges emerge between review cycles.

Data-plane focus can miss management-plane dominance

Teams often model workload-to-workload movement but under-model management-plane authority. In many incidents, management-plane control determines whether compromise remains bounded or becomes systemic.

Service trust assumptions can hide path amplifiers

Platform services are frequently treated as safe intermediaries by default. When those services operate with broad authority, they can unintentionally compress attacker effort and increase compromise speed.

Path length is not the same as path difficulty

A long path with permissive trust edges can be easier than a short path with strong mediation. Sequence depth alone is not a meaningful risk metric without resistance quality at each edge.

Best Practices

Model paths across all three planes together

Require architecture review artifacts to show identity, management, and data-plane traversal logic in one model. Split-plane analysis hides systemic reachability.

Identify and harden pivot services

Catalog services that can transform limited compromise into broad authority. These are architectural choke candidates and should receive disproportionate design scrutiny.

Track inherited authority as changing exposure

Inherited roles and delegated scopes are dynamic risk surfaces. Revalidate them at each major platform change, not just during identity projects.

Write findings as consequence chains

Describe exposures as reachable sequences, for example: “workload identity A can invoke service B, which can alter policy C, enabling access to asset D.” This format drives action better than isolated control findings.

🍺

Brewed Insight: Attack paths turn architecture from a control checklist into a consequence model. If you can’t explain what a compromise could actually reach from here, you don’t yet understand your real risk - no matter how tidy the control inventory looks.

Learn More

Why Security Controls Fail in Combination

Tue, 21 Jul 2026 00:00:00 +1000

Security architecture discussions often begin with a checklist of controls and end with a false sense of assurance.

That pattern is understandable. Control inventories are easy to report, easy to compare, and easy to govern. They are also a poor proxy for how an adversary experiences your environment.

In real incidents, compromise rarely succeeds because one control is missing. It succeeds because multiple controls share hidden assumptions, depend on the same authority paths, or fail open when operational pressure increases. Defensive architecture is therefore less about counting controls and more about reasoning about control behavior as a coupled system.

The Mental Model

A useful model is to treat security as a network of trust decisions, not a stack of independent products.

Every control exists inside a dependency context: an identity source, an administrative authority, a routing and name resolution path, a logging pipeline, and a recovery mechanism. If two controls share too many of these dependencies, they are not truly independent layers. They are multiple interfaces to the same underlying trust decision.

This matters because incident resilience depends on independence. When an attacker compromises one trust domain, the architecture should force costly pivots. If the architecture instead allows inherited authority to flow through management plane, identity plane, and data plane simultaneously, failure propagation becomes fast and predictable.

A practical framing for senior design reviews is:

Control presence: Is the safeguard deployed?
Control independence: Does it rely on a different trust path than adjacent controls?
Control consequence: If bypassed, how much authority can propagate before containment is guaranteed?

Without this progression, review outcomes become inventory-centric and blind to combinational failure.

Architecture decision standard

A design should not be approved unless it can satisfy four explicit tests:

Independence test: at least two high-consequence controls rely on different authority chains, not the same management group or subscription-level identity inheritance.
Propagation test: compromise of a workload identity cannot directly or transitively alter policy, key management, or routing controls outside its intended resource-group boundary.
Override test: emergency access and policy exemptions are time-bounded, owner-assigned, and observable through a dedicated review path.
Containment test: the team can state, in one sentence, where authority propagation must stop and which controls enforce that stop condition.

If a review can prove control presence but cannot prove compromise stop points, the architecture is not defensible.

How It Really Works

Combinational failure usually emerges from three recurring conditions.

Shared assumptions across layers

Network restrictions, identity policies, and platform hardening are often designed by different teams, but they inherit the same upstream trust assumptions. If that upstream assumption fails, all three layers degrade together. This is why “defense in depth” claims can collapse in minutes under adversarial pressure.

Hidden transitive dependencies

Many environments correctly lock direct access to critical assets while leaving indirect operational paths broad. Automation identities, delegated administration, and service integrations can create transitive reachability that bypasses intended control boundaries without violating any single policy statement.

Operational override paths

Production urgency creates temporary exceptions that become permanent architecture. Break-glass access, broad troubleshooting roles, and emergency routing shortcuts are often rational in isolation but collectively create low-friction compromise pathways.

flowchart TD A[Initial foothold] --> B{Can attacker influence trusted identity?} B -->|Yes| C[Identity-plane authority expansion] B -->|No| D[Local compromise only] C --> E{Shared dependency with network/platform controls?} E -->|Yes| F[Multiple controls degrade together] E -->|No| G[Partial resistance remains] F --> H{Operational override path exists?} H -->|Yes| I[Rapid systemic failure propagation] H -->|No| J[Constrained lateral options] J --> K[Containment window] I --> L[High-consequence exposure event]

The diagram reflects a core point: control interaction quality, not control quantity, determines whether compromise remains local or becomes systemic.

Real-World Impact

This architectural lens changes outcomes because it shifts decision quality before incidents, not after them.

Design review quality

When reviewers evaluate control independence, architecture conversations become sharper. Teams stop accepting statements like “we have MFA, segmentation, and monitoring” as proof of resilience. They begin asking whether those controls depend on the same identity authority, the same management plane role chain, or the same exception model.

Failure predictability

Combinational analysis increases predictability under stress. If trust concentration and propagation paths are explicit, responders can anticipate where compromise may spread and stage containment actions faster. If the architecture is evaluated only by standalone controls, the first hours of an incident become discovery work.

Governance effectiveness

Governance programs improve when risk narratives are written as dependency and consequence paths instead of policy counts. Executives can prioritize investments when they can see how one trust boundary flaw undermines multiple controls and multiplies business impact.

Platform scale safety

As cloud estates grow, combinational failure risk grows nonlinearly. New services inherit old trust assumptions and expand transitive reach unless boundaries are intentionally revalidated. The defensive architecture discipline keeps growth from silently amplifying consequence.

Gotchas and Edge Cases

Even strong programs fail here because local correctness can still produce global weakness.

Passing control tests can hide systemic weakness

Isolated control validation often passes while cross-plane behavior remains unsafe. A well-configured network boundary does not guarantee containment if trusted workload identities can still invoke privileged management operations indirectly.

“Internal” service trust is frequently over-broad

Teams often allow broad communication and invocation rights between platform services because they are all enterprise-managed. Under compromise, those assumptions convert internal reliability channels into attacker mobility channels.

Recovery design can reintroduce broad authority

Backup and recovery workflows are essential, but they sometimes rely on highly privileged identities and broad administrative scopes that bypass normal controls. If those pathways are not constrained and monitored, resilience tooling becomes part of the exposure surface.

Exception debt grows quietly

Most security degradation does not come from dramatic policy changes. It comes from accumulated exceptions that were each “temporary.” Over time, those edges form a stable bypass graph that no single team owns.

Best Practices

Review control sets as interacting systems

Require architecture reviews to map trust relationships and dependency paths between identity, network, platform, and operations. If controls cannot be shown as independent under compromise, redesign before scale.

Measure independence, not only existence

For each major safeguard, record which upstream trust assumptions it depends on. Prioritize designs that reduce shared dependencies across critical controls.

Make consequence boundaries explicit

For high-value assets and control-plane functions, require teams to define the smallest guaranteed containment boundary and the evidence that boundary holds under adversarial conditions.

Treat exceptions as architecture changes

Temporary overrides should carry owner, expiry, and consequence analysis. Exceptions are not operational trivia; they are trust-graph edits that must be governed as first-class architecture events.

🍺

Brewed Insight: Security controls don’t fail independently in mature cloud estates. They fail in correlated patterns, usually because two “separate” controls were quietly leaning on the same shared trust assumption the whole time.

Learn More

VNRA Design Trade-offs: When Abstraction Helps, and When It Hides the Route Problem

Thu, 16 Jul 2026 00:00:00 +1000

A routing design can look cleaner at exactly the moment it becomes harder to trust.

That is the trap with abstraction in Azure networking. Remove enough visible route objects and the environment starts to feel simpler. Fewer route tables. Fewer subnet-level associations. Less repeated administrative work.

But packets do not care whether the control surface looks tidy.

They care which route wins.

That is the right lens for Virtual Network Routing Appliance (VNRA). Not whether it reduces configuration sprawl, but whether it makes forwarding behaviour easier or harder to predict when the environment changes, exceptions appear, or incidents land at 2 am.

The hard truth is this: if introducing VNRA still leaves you needing UDR exceptions to preserve determinism, the design has already told you native routing was the better default.

The Mental Model

The common assumption is that fewer explicit routing objects means lower complexity.

That assumption fails surprisingly often in Azure.

Operational simplicity is not the same as configuration brevity. A design with fewer visible route artefacts can still be more complex if engineers can no longer explain packet path decisions from effective route evidence at the subnet or workload boundary.

That is the mental model shift this topic needs:

VNRA does not automatically simplify routing. It moves complexity away from explicit route authorship and into interpretation of effective forwarding behaviour.

Sometimes that is exactly what you want. If you have broad, repeated intent across many segments, centralising that intent can reduce drift and make change safer.

Sometimes it is the wrong trade. If the design depends on carve-outs, bypasses, and subnet-specific behaviour to stay safe, abstraction does not remove complexity. It just hides it behind a cleaner control surface.

That distinction matters more than the feature itself.

How It Really Works

From a data plane-first perspective, VNRA matters only if it changes what route wins for a packet and how confidently an operator can predict that outcome.

That means the useful questions are not:

Did VNRA reduce the number of route tables?
Did we centralise routing intent?
Does the architecture diagram look cleaner?

The useful questions are:

What effective routes now appear on the workload NIC?
Which next hop actually wins for the destination that matters?
Can an engineer explain why that route won over competing system, Border Gateway Protocol (BGP), or user-defined route (UDR) inputs?
If topology or propagated reachability changes, is the winning path still obvious?

That last question is where abstraction either earns its keep or quietly becomes debt.

VNRA does not replace Azure route selection mechanics. It lives within them. Effective forwarding still depends on the routes that exist, their prefixes, their source, and which one wins on the interface that sends the packet.

So the design issue is not whether your routing intent is elegant. The design issue is whether the resulting route outcome remains explainable without reconstructing platform-wide logic during an incident.

If it does, abstraction may be helping.

If it does not, the environment has become easier to declare and harder to operate.

The practical test

A simple test cuts through most of the marketing-grade ambiguity:

If an engineer cannot predict the winning route for a representative subnet from effective route evidence alone, VNRA is the wrong abstraction for that design.

That is not a philosophical position. It is an operational one.

If packet forwarding must be inferred from a combination of central intent, remembered exceptions, propagated routes, and tribal knowledge, then the design has traded route sprawl for uncertainty. That is not simplification in any production sense that matters.

When VNRA Actually Reduces Complexity

VNRA is useful when it removes repeated human decision-making without degrading path clarity.

That usually means the environment has a small number of broad forwarding patterns repeated at scale.

Repeated intent across many segments

If many subnets are meant to treat the same destinations the same way, VNRA can reduce one of the most common Azure networking failure modes: inconsistent route expression across supposedly equivalent segments.

The win here is not aesthetic. It is behavioural.

You are reducing the number of places where a missed route update, stale association, or inconsistent exception can create divergent packet paths. In other words, you are reducing accidental difference.

That changes how you design and operate the network:

less repeated route authoring
less drift between equivalent subnets
less manual verification after each broad routing change

In that shape of environment, abstraction can be a real operational improvement.

Route sprawl is already the dominant risk

There are environments where explicit routing is theoretically deterministic but practically fragile because nobody can maintain consistency across all the places where route control has been distributed.

If every change requires validating route logic across a growing set of subnet route tables, the problem is no longer “explicit routing is more precise”. The problem is “the precision is not surviving contact with reality”.

VNRA can help in those cases because it reduces the number of repeated decisions humans need to make and re-make over time.

That is a valid simplification, but only if effective outcomes remain easy to inspect.

Your routing policy is intentionally broad

If your design intent is something like “all these application segments should follow the same inspected egress path” and that rule genuinely holds without a long list of exceptions, VNRA aligns well with the architecture.

Broad routing intent is where abstraction tends to pay off. The platform is doing less interpretive work because the design itself is not asking for much nuance.

When VNRA Increases Complexity

This is where the abstraction tends to get overused.

When determinism is the real requirement

If you need to explain packet path correctness from the subnet boundary, native explicit routing is often the better tool.

That is particularly true in segmented, compliance-sensitive, or troubleshooting-heavy environments where the operational question is not “what was the intended design?” but “why did this interface send traffic to that next hop?”.

In those environments, visible route control is often a strength rather than a burden.

A route table may be verbose, but verbosity is not the same as ambiguity. In many production environments, explicit routing is easier to trust precisely because it is easier to inspect locally.

When exceptions are structural, not occasional

This is the clearest anti-fit signal.

If your routing model depends on bypasses, carve-outs, one-off service insertion paths, or subnet-specific forwarding rules to preserve correctness, VNRA is not simplifying the network. It is hiding complexity behind a cleaner control surface.

That is the point where the abstraction starts working against the architecture.

And once UDR exceptions appear to recover lost determinism, the design has usually answered the question for you:

If introducing VNRA means you still need UDR exceptions to preserve determinism, native routing was the better default.

That is not because UDRs are inherently superior. It is because the network is telling you it needs explicit local control more than centralised intent.

When the design becomes mixed by necessity

Mixed routing models deserve suspicion.

If the environment increasingly relies on both VNRA-shaped behaviour and carefully placed UDR overrides, you now have two jobs:

understand the abstract forwarding intent
understand where explicit route control is compensating for it

That is usually worse than choosing one primary model and committing to it.

Mixed models often emerge gradually. Nobody plans them. They appear as small “just for this subnet” corrections that accumulate until the architecture diagram still looks elegant but the data plane no longer is.

When troubleshooting depends on local evidence

The best operational routing designs let the engineer closest to the issue answer basic forwarding questions without escalating into architecture archaeology.

If local teams cannot explain packet path from effective route evidence on the affected NIC or subnet, incident response slows down. Ownership becomes fuzzy. Mean time to innocence expands. The actual route problem takes longer to isolate because too much of the forwarding logic exists outside the operator’s immediate field of view.

That is not just a tooling problem. It is a design problem.

Native Simplicity vs VNRA-Influenced Simplicity

The wrong comparison is “manual versus automated”.

The right comparison is “locally explainable versus centrally abstracted”.

Simpler native routing

A simpler native routing design usually has:

a small number of route sources
constrained use of UDRs
clear propagation boundaries
few exceptions
forwarding behaviour that can be explained from the affected subnet or NIC

This often looks less sophisticated than an intent-driven design, but for environments that value explainability, it is operationally stronger.

Simpler VNRA-influenced routing

A VNRA-influenced design is genuinely simpler when:

forwarding intent is repetitive
exceptions are rare
route source interactions are stable
effective route outcomes remain easy to inspect
another engineer can predict the winning path without reconstructing hidden logic

If those conditions are not true, the abstraction is not reducing complexity. It is displacing it.

A Quick Decision Filter

flowchart TD A[Need to shape routing behaviour] --> B{Is forwarding intent mostly repetitive?} B -->|No| C[Prefer native explicit routing] B -->|Yes| D{Are exceptions rare and non-structural?} D -->|No| C D -->|Yes| E{Can engineers predict the winning route from effective route evidence?} E -->|No| C E -->|Yes| F[VNRA may reduce operational complexity] F --> G{Do you still need UDR exceptions to preserve determinism?} G -->|Yes| C G -->|No| H[VNRA is a reasonable fit]

This is not a deployment pattern. It is a design sanity check.

The key branch is the last one. Once UDR exceptions are required to recover predictable behaviour, the abstraction is usually no longer earning its place.

Real-World Impact

So how would this change something you design, deploy, or operate?

It should change what you optimise for during design review.

If your environment is dominated by repeated routing intent and low exception density, VNRA may reduce operational drag and make broad change safer.

If your environment depends on local path explainability, strict exception handling, or per-subnet determinism, then simpler native routing is often the stronger architecture even if it looks less elegant in a diagram.

That affects several production concerns.

Design

Do not ask whether VNRA can express the intended routing model. Ask whether the resulting packet paths will remain obvious once exceptions, failures, and topology change arrive.

A design that only looks simple while it remains idealised is not simple.

Reliability

Reliability is not just about whether traffic flows. It is about whether engineers can predict and restore correct forwarding under change.

A routing abstraction that makes incident behaviour harder to reason about is increasing operational risk even if it reduces control-plane sprawl.

Security

Security controls often depend on proving that traffic follows expected paths. If that proof requires too much interpretation, governance gets weaker even when the stated policy is sound.

Visible determinism is often more useful than elegant intent.

Scalability

VNRA can scale route intent. That part is real.

But if only senior engineers can interpret the resulting forwarding behaviour, then reasoning does not scale with configuration. You have moved the bottleneck rather than removed it.

Implementation Example

This post intentionally avoids deployment walkthroughs, but the design trade-off still needs a concrete validation artefact.

The most useful artefact is not a template. It is effective route evidence taken from representative workload interfaces.

For example:

1
2
3
4


az network nic show-effective-route-table \
 --resource-group rg-app-prod \
 --name nic-app-01 \
 --output table

That command by itself is not the point. The point is what you can conclude from the output.

Use it as a design review heuristic against representative interfaces:

a standard application subnet
an exception subnet
a subnet expected to receive propagated routes
a subnet expected to bypass a broader forwarding pattern

Then ask four hard questions:

Can I identify the winning route for the destination that matters?
Can I explain why it won over system, BGP, or UDR alternatives?
Would another engineer reach the same conclusion quickly?
If I need a UDR exception to make this output predictable, why am I using VNRA here at all?

Those questions are more useful than counting route tables or celebrating centralised intent.

What healthy looks like

A VNRA-influenced design is probably doing its job if:

route outcomes are consistent across equivalent subnets
exception cases are genuinely rare
effective route outputs are still easy to interpret
path expectations survive topology change without surprise

What trouble looks like

The abstraction is probably becoming a liability if:

exception subnets keep appearing
engineers disagree on expected next hop before checking the NIC
incident reviews repeatedly require reconstructing central intent to explain local traffic
UDRs are being added to recover predictability rather than express genuinely separate policy

Those are not implementation details. They are architecture signals.

Gotchas & Edge Cases

A clean control surface can mask a brittle route model

The danger is not that VNRA hides routes. The danger is that it can hide the growth of exceptions until the environment becomes mixed and harder to reason about than the explicit design it replaced.

Exception growth is gradual, not dramatic

Most designs do not start complicated. They become complicated one “special case” at a time. That matters because VNRA may still look successful in design documentation long after the forwarding model has become messy in practice.

Effective routes show outcomes, not intent quality

A route table output can tell you which path wins. It cannot tell you whether the abstraction producing that path is still the right architectural choice. You still need judgement about whether the model is converging on clarity or drift.

Stable today does not mean understandable tomorrow

A VNRA design that behaves predictably under today’s topology may become opaque once propagated routes, segmentation changes, or inspection exceptions increase. Re-checking effective outcomes after change is not optional.

Best Practices

Default to explicit routing when explainability is a hard requirement

If packet path correctness must be provable from the workload boundary, start with native routing and make abstraction justify itself.

Use VNRA for repetition, not nuance

If the value of the design comes from broad repeated intent, abstraction can help. If the value comes from careful exceptions, keep the routing model explicit.

Treat new UDR exceptions as an architecture warning

Do not see them only as implementation details. If UDRs are being added to restore deterministic behaviour inside a VNRA-shaped design, revisit the abstraction choice.

Review route evidence, not just design intent

The design is only as good as the effective routes it produces on real interfaces. Validation should happen at the NIC, not just in the architecture meeting.

🍺

Brewed Insight: VNRA is useful when it removes repeated routing decisions without making packet paths harder to prove. Once you need UDR exceptions to recover determinism, the network is telling you it wanted explicit control all along.

Learn More

When Deterministic Routes Fail Loudly in Silence: VNRA Failure Modes and Non-Obvious Behaviour

Tue, 14 Jul 2026 00:00:00 +1000

There is a particular kind of cloud failure that wastes hours: the route looks right, the next hop looks right, and the workload still cannot talk.

That is where Azure Virtual Network Routing Appliance (VNRA) gets interesting. Not because it invents strange new routing failures, but because it changes the shape of familiar ones. VNRA can make routing intent more deterministic. The trade is that more traffic can end up depending on the same forwarding model, which means failures become less local, less obvious, and harder to isolate quickly.

That is the real point of this post.

In earlier posts we covered route selection, effective routes, and VNRA interactions with system routes, User Defined Routes (UDRs), and Border Gateway Protocol (BGP). This post stays in the unpleasant part of the story: what happens when the selected route still does not translate cleanly into successful packet delivery.

The practical question is the one that matters:

How would this change something I design, deploy, or operate?

It means that if you adopt VNRA, you should stop thinking in terms of isolated route-table correctness and start thinking in terms of shared forwarding dependencies. VNRA can improve determinism in intended pathing, but that same determinism can widen failure impact and muddy root cause analysis.

The Mental Model

A common assumption in Azure networking goes like this:

If the effective route table shows the expected prefix and next hop, the traffic should work.

That assumption is good enough right up until it costs you an incident.

Effective routes are useful, but they do not prove end-to-end packet success. They show the route outcome Azure is exposing for that network interface. They do not prove that the selected next hop is functionally viable for the flow, that the reverse path is aligned, or that the broader forwarding dependency behind that route is healthy.

That limitation is not new. Azure has always had a gap between visible route state and actual application outcome. VNRA does not invent that gap. What it changes is how much traffic can now share the same pathing assumptions.

So the mental model shift is this:

VNRA is valuable because it improves determinism in routing intent. VNRA is risky because that determinism often depends on more centralised forwarding behaviour, which reduces failure isolation.

That is the trade.

How It Really Works

The important thing to say plainly is this: asymmetry, blackholing, and healthy-looking route tables alongside unhealthy workloads are not new Azure problems.

You could already get there with combinations of system routes, propagated BGP paths, peering behaviour, and virtual appliance next hops. VNRA does not create entirely new classes of routing pain. What it changes is the scope of the pain.

Without VNRA, a routing mistake is often easier to keep local. A bad route table association, a wrong UDR, or an unexpected propagated path may still be painful, but the blast radius is frequently narrower and the dependency graph is simpler to reason about.

With VNRA, more flows can become dependent on the same packet-path model. That improves consistency of routing intent. It also means a single faulty assumption, unavailable appliance path, or return-path mismatch can affect many otherwise unrelated flows at once.

In practical terms:

route selection may be more predictable
traffic steering may be more consistent
forwarding dependence may be more centralised
failures may stop looking local even when the first symptom is

That is why VNRA is not just a control-plane feature discussion. It is a data-plane consequence discussion.

flowchart LR A[Workload] --> B{Selected route} B -->|System / UDR / BGP / VNRA-influenced| C[Chosen forwarding path] C --> D{Path viable for flow?} D -->|Yes| E[Forward delivery succeeds] D -->|No| F[Timeout, blackhole, or reset] E --> G{Return path aligned?} G -->|Yes| H[Healthy session] G -->|No| I[Asymmetry breaks flow] subgraph VNRA Effect J[More deterministic path intent] K[Less isolated failure domains] end J --> C K --> F K --> I

The diagram is intentionally simple. The point is not to describe every routing branch. The point is to show that deterministic route intent and successful flow completion are related, but not equivalent.

Failure Mode 1: The Route Is Present, but the Path Dependency Is Not Healthy

This is the most common trap in the article’s topic space, and the easiest one to misread.

The effective route table may show:

the expected prefix
the expected next hop type
the expected appliance IP
a perfectly reasonable route source

That tells you the network interface has a selected route outcome for that prefix. It does not tell you that the forwarding path behind that choice is healthy for the traffic in question.

In a VNRA design, that distinction matters more because the selected path may represent a shared forwarding dependency for multiple flows, not just a one-off subnet rule.

At workload level, you may see:

TCP connection timeouts
repeated retransmits
failed health probes
application-level unreachability despite apparently correct route state

This is where the practical operational change begins:

In a VNRA design, a healthy-looking effective route table is evidence of intended path selection, not proof of successful packet delivery.

That should change how you interpret incidents. The first question is no longer just “is the route there?” It is “is the selected path still viable in both directions for this flow?”

Failure Mode 2: More Deterministic Intent, Less Local Failure

VNRA’s appeal is that it can make pathing behaviour more deliberate. That is good architecture when you need predictable inspection, controlled transit, or consistent route outcomes across multiple segments.

The catch is that this predictability often comes from shared forwarding dependence.

A subnet-level UDR problem is usually local enough that teams learn its boundary quickly. A VNRA-shaped path issue can surface first on one workload while already affecting:

multiple spokes
multiple application tiers
east-west traffic classes
north-south inspection paths
flows that used to fail independently

This is the part many designs underweight. VNRA does not just help decide where traffic should go. It can also make many different traffic classes rely on the same decision machinery.

That means the failure mode changes from:

this subnet is wrong

to:

this forwarding model is wrong

That is a very different investigation.

Failure Mode 3: Asymmetry Still Exists — It Just Becomes Easier to Misread

Asymmetric routing is not a VNRA invention. But VNRA can make asymmetry harder to spot because the forward path may look more intentional than before.

For example, traffic from a spoke workload might be steered cleanly through a central routing or inspection path. The return traffic might still have a valid route that bypasses the same path entirely. From a narrow route-selection perspective, both directions may appear explainable. From a workload perspective, the session breaks.

That matters most for:

stateful inspection paths
session-sensitive applications
traffic where one direction is centralised and the other is still following a simpler platform path
environments where different teams control different parts of route intent

The observable symptoms are familiar:

intermittent resets
one-way success
handshake success followed by application failure
some prefixes working while others fail
inconsistent behaviour between test tools and real applications

Here is the simplified flow:

sequenceDiagram participant VM as Spoke VM participant VNRA as VNRA-directed path participant APP as Target service VM->>VNRA: Forward path follows deterministic routed intent VNRA->>APP: Request delivered APP-->>VM: Return path follows different valid route Note over VM,APP: Session fails due to asymmetry or state mismatch

The non-obvious part is not that asymmetry exists. It is that a more deliberate forward path can make engineers assume the whole flow is now under the same control model when it is not.

Failure Mode 4: BGP Can Be Healthy While the Flow Is Still Broken

BGP often gives teams confidence because it provides visible route exchange and concrete prefixes to inspect. If advertisements are present and effective routes reflect the expected propagated entries, people are tempted to clear routing from the list of suspects.

That is too generous in a VNRA design.

BGP health can confirm that route information is present and propagating as expected. It cannot by itself confirm that the forwarding path shaped by those routes is viable, symmetric, or still operationally useful for the workload.

This is not a criticism of BGP. It is a reminder of scope.

A route can be:

learned correctly
selected correctly
visible correctly

and still participate in a broken end-to-end flow because the actual forwarding dependency behind the selected path is impaired or mismatched in one direction.

In other words:

BGP tells you that route information is healthy. It does not tell you that the VNRA-dependent path using that information is healthy.

That distinction becomes more important as routing intent gets centralised.

Failure Mode 5: Blackholing Without an Obvious Control-Plane Event

Some routing failures are loud. A route disappears. A peer drops. A path withdraws. The incident starts with a visible control-plane change.

The more frustrating failures are the quiet ones.

In a VNRA-centred design, traffic can fail because the selected forwarding path is no longer functionally useful, while the route outcome presented to the workload still looks entirely plausible. That does not mean Azure is lying about the route. It means the route view has reached the limit of what it can prove.

That usually shows up as:

timeouts instead of explicit rejects
selective failure by prefix or traffic class
health checks passing from one location and failing from another
retries that obscure the pattern rather than clarify it

This is why blackholing in cloud environments is so often misdiagnosed. People look for missing configuration, when the real problem is a still-selected but no-longer-usable path dependency.

Real-World Impact

Design

If VNRA is in the architecture, you are not merely defining routes. You are defining a shared forwarding model.

That should change design review questions. Instead of asking only whether the route logic is correct, ask:

which traffic classes now rely on the same path decision
which of those require symmetric return
what fails together if the path remains selected but is not viable in practice
which paths should not be centralised, even if they could be

That is the architectural trade in plain language:

VNRA improves determinism in routing intent, but it weakens failure isolation when too much traffic depends on the same forwarding behaviour.

Reliability

Route correctness and service correctness are not the same thing.

In a VNRA design, reliability depends on whether the selected path is usable for the full flow, not just whether the correct prefix appears in effective routes.

Operations

The operational change is simple, but important:

Do not treat effective routes as proof of successful delivery. Treat them as proof of selected intent.

That changes incident reasoning. A healthy-looking route table should narrow your questions, not end them.

Security

Central inspection or routed enforcement paths benefit from deterministic steering. They also become more sensitive to asymmetry and hidden path dependency failure. If the design assumes inspection is guaranteed because the route intent says so, the design is trusting control-plane evidence too much.

Implementation Example

This series explicitly excludes step-by-step deployment guidance, so this example is intentionally narrow. The goal is not to show how to build VNRA. The goal is to show why visible route state should be interpreted carefully.

An Azure CLI example for effective route inspection:

1
2
3
4


az network nic show-effective-route-table \
 --resource-group rg-spoke-prod \
 --name nic-app-01 \
 --output table

Illustrative output:

1
2
3
4
5
6


Source State Address Prefix Next Hop Type Next Hop IP
-------- ------- ---------------- -------------------- -----------
User Active 10.20.15.0/24 VirtualAppliance 10.10.2.4
User Active 0.0.0.0/0 VirtualAppliance 10.10.2.4
BGP Active 172.16.20.0/24 VirtualNetworkGateway
Default Active 10.0.0.0/8 VNetPeering

That output can support a valid conclusion:

the workload has selected route outcomes for those prefixes
the appliance path is part of intended forwarding
BGP propagation is visible
peering routes are present

What it cannot support on its own is the stronger conclusion many engineers want to make:

the selected appliance path is healthy for this flow
the reverse path is aligned
the session will complete successfully

That is the limit worth respecting.

To make the dependency concentration concrete, here is a minimal Bicep-style route table fragment showing multiple traffic intents using the same next hop:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


resource spokeRouteTable 'Microsoft.Network/routeTables@2024-05-01' = {
 name: 'rt-spoke-app'
 location: resourceGroup().location
 properties: {
 disableBgpRoutePropagation: false
 routes: [
 {
 name: 'private-segment-via-appliance'
 properties: {
 addressPrefix: '10.20.0.0/16'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.10.2.4'
 }
 }
 {
 name: 'default-via-appliance'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.10.2.4'
 }
 }
 ]
 }
}

The deployment syntax is not the point here. The point is architectural:

deterministic path intent often comes from concentrating multiple route decisions onto the same forwarding dependency.

That is exactly why the resulting failure domain deserves more scrutiny.

Gotchas & Edge Cases

Effective routes are necessary, but not sufficient

They help explain selected route intent. They do not validate session success.

A cleaner forward path can hide a dirty return path

VNRA can make the outbound decision look more deliberate without guaranteeing bidirectional symmetry.

Familiar failures can look more novel than they are

Blackholing and asymmetry are old problems. The novelty is often the wider blast radius and less obvious dependency chain.

“Routing looks healthy” is often an incomplete statement

Healthy route visibility can coexist with unhealthy forwarding outcomes.

Central path control increases consequence before it increases complexity

The hardest part is not always more routes. It is more traffic relying on the same route behaviour.

Best Practices

Design for shared dependency awareness

If VNRA is central to pathing, treat that as a deliberate dependency decision, not an implementation detail.

Separate route selection confidence from packet delivery confidence

These are related signals, not interchangeable ones.

Be explicit about symmetry requirements

If a flow depends on stateful devices or inspection paths, assume return-path design needs as much scrutiny as forward-path design.

Keep some paths simple on purpose

If a traffic class does not benefit materially from centralised path control, do not centralise it just because you can.

Investigate incidents at the forwarding-model level

When VNRA is involved, local symptoms may still be expressions of a central path dependency problem.

🍺

Brewed Insight: VNRA’s strength is that it makes routing intent more deterministic. Its cost is that deterministic intent often rides on less isolated failure domains. If you only verify the route table, you are checking the recipe card and assuming the coffee tasted good.

Learn More

When BGP Stops Being Boss: VNRA and Propagated Routes in Azure

Thu, 09 Jul 2026 00:00:00 +1000

BGP has a habit of making engineers feel safe.

If the gateway is up and the prefix is propagated, the instinct is to relax. Azure learned the route, the subnet can see it, and the packet should follow accordingly. In a standard hybrid mental model, that feels reasonable.

VNRA is where that comfort starts to fall apart.

This is the key point for this post:

A propagated BGP route can remain visible in Azure without remaining authoritative for forwarding once VNRA governs the packet path.

That is not just a troubleshooting nuance. It changes how you judge hybrid determinism, what evidence you trust during incidents, and whether a route table is telling you the thing you think it is.

The Mental Model

The common assumption is straightforward:

If a subnet has a propagated route from a VPN Gateway or ExpressRoute gateway, that route is the authority for forwarding unless something more specific overrides it.

That model works well enough until VNRA enters the picture. Then the mistake is not that Azure stops learning the route. The mistake is assuming that learning, visibility, and forwarding authority are still the same thing.

They are not.

Once VNRA participates in the routing outcome, a propagated route may still be present while no longer being the deciding authority for how traffic is actually delivered.

That is the mental shift:

BGP propagation tells Azure a prefix is reachable
VNRA can change whether that propagated route remains authoritative for forwarding
Effective routing evidence is no longer the same thing as forwarding truth

If you miss that distinction, hybrid routing starts to look deterministic on paper and conditional in production.

How It Really Works

This series is deliberately data plane first, so the question here is not “did Azure learn the route?” but “what governs forwarding once both gateway propagation and VNRA are involved?”

Propagation and authority are not the same thing

A route propagated from a gateway into a subnet tells you Azure has imported reachability information for that prefix. That is a control-plane fact.

The mistake is treating that fact as conclusive proof that the propagated route still governs forwarding for that subnet.

With VNRA in play, that is no longer a safe assumption.

A visible route with VirtualNetworkGateway as its source can still exist while VNRA is the stronger determinant of the realised path. Put bluntly:

Visibility of a propagated route does not guarantee authority over forwarding.

That is the actual fault line in hybrid designs using VNRA.

VNRA changes route authority, not just packet inspection

It is tempting to talk about VNRA as though it merely influences where packets are observed or inspected. That framing is too weak.

The important change is that VNRA can alter which route source remains authoritative in practice for a given path. Once that happens, the gateway-learned route is still part of the routing picture, but it is no longer the decisive actor engineers often assume it to be.

That is why hybrid issues in VNRA-connected designs can look contradictory:

the prefix is present
the gateway is healthy
the effective route table looks fine
traffic behaviour still does not align with a gateway-authoritative path

That is not necessarily a gateway problem. It is often a route authority problem.

The practical boundary is where forwarding stops obeying propagation

A useful way to reason about this is to stop asking whether BGP propagation exists and start asking where it remains authoritative.

Once VNRA governs the packet path for a subnet or transit flow, propagated routes may still be true in the sense that Azure has learned them, but they stop being authoritative in the way architects and operators usually care about: they no longer guarantee the forwarding outcome.

That is the decision boundary that matters.

If VNRA governs the path, the propagated route becomes evidence of learned reachability, not proof that the gateway still governs forwarding behaviour.

A Concrete Hybrid Scenario

Consider a spoke workload subnet in a hybrid environment.

The subnet receives propagated on-premises prefixes from a hub-connected ExpressRoute or VPN gateway. A VM in that subnet shows the expected private prefixes in its effective routes, sourced from VirtualNetworkGateway.

An engineer checks the route table and concludes the hybrid path is behaving as designed.

That conclusion may be wrong.

If VNRA governs forwarding for that subnet’s traffic, then the visible gateway-propagated route is no longer enough to prove that the gateway remains the authority over delivery. The route is present, but the packet path is now being decided elsewhere.

That is the trap.

flowchart LR A[Spoke workload subnet] B[Effective route shows on-prem prefix
Source: VirtualNetworkGateway] C[VNRA governs forwarding path] D[Observed traffic does not behave as though gateway propagation is authoritative] E[Operator assumes gateway path is still decisive] A --> B B --> E A --> C C --> D

The point of this flow is simple: route visibility and forwarding authority can diverge once VNRA is in the path.

Real-World Impact

This is where the article either matters or it does not.

Hybrid determinism is weaker than the route table suggests

A lot of Azure hybrid designs quietly assume that propagated gateway routes provide stable authority across workload subnets. VNRA weakens that assumption.

If the design depends on “the subnet can see the propagated route, therefore that route governs forwarding”, the design is less deterministic than it looks.

How would this change something you design, deploy, or operate?

It means you should stop treating propagated BGP visibility as proof of packet path in VNRA-connected hybrid environments. For design reviews, that changes what evidence is acceptable. For operations, it changes what counts as validation.

Effective routes become evidence, not authority

This is the stronger operational opinion the article needs to make explicit:

In VNRA-affected hybrid paths, effective routes are useful evidence of learned reachability, but they are no longer authoritative proof of forwarding behaviour.

That is not because effective routes are wrong. It is because they answer a narrower question than many engineers use them for.

They can tell you Azure learned the prefix.

They cannot, on their own, prove that the gateway-learned route still governs the realised path once VNRA has altered route authority for forwarding.

Incident triage needs a different first question

Without VNRA, it is reasonable to begin with:

did the gateway lose the route?
did BGP stop propagating the prefix?
is the effective route missing?

With VNRA in the picture, the earlier question is often:

Does the propagated route still have forwarding authority for this subnet, or is VNRA now the governing path decision?

That is a materially better triage question because it separates control-plane health from forwarding truth.

Subnet-level behaviour matters more than VNet-level assumptions

One of the quieter risks here is over-generalising from a broad topology statement like “the VNet has the propagated route”.

That is too coarse.

In VNRA-influenced environments, the question is whether a particular subnet and path still behave as though the gateway-propagated route is authoritative. If not, route visibility at a wider scope is operationally misleading.

Implementation Example

This series excludes deployment guidance, but an operational article still needs a concrete artefact.

A common starting point is to inspect effective routes on a workload NIC.

Azure CLI: inspect effective routes

1
2
3
4


az network nic show-effective-route-table \
 --resource-group rg-spoke-prod \
 --name nic-app-01 \
 --output table

Example output:

1
2
3
4
5
6


Source State Address Prefix Next Hop Type
--------------------- ------- ------------------ ---------------------
Default Active 10.20.0.0/16 VnetLocal
VirtualNetworkGateway Active 172.16.0.0/12 VirtualNetworkGateway
VirtualNetworkGateway Active 192.168.100.0/24 VirtualNetworkGateway
Default Active 0.0.0.0/0 Internet

The operational mistake is to stop here and conclude:

“The on-prem route is present, so the gateway still governs forwarding.”

That conclusion is not justified in a VNRA scenario.

A better interpretation is:

Azure has learned the route
the subnet can see the propagated prefix
you still have not proved that the propagated route remains authoritative for forwarding

That distinction changes your next action. You move from route inspection to path validation.

In practice, that means validating observed behaviour with whichever telemetry is available in your environment, such as:

flow observations on the forwarding path
packet capture on test workloads
appliance-side session or forwarding logs
bidirectional connectivity tests between Azure and on-premises endpoints

The exact tool is less important than the principle: if forwarding behaviour and effective routes disagree, trust the forwarding outcome.

Gotchas & Edge Cases

A healthy gateway does not prove authoritative forwarding

Engineers often stop investigating once they confirm the gateway is up and prefixes are propagated. In a VNRA design, that only proves the control plane still knows the route. It does not prove the gateway remains the decisive authority for delivery.

Route visibility can create false certainty

The more “correct” the effective route table looks, the easier it is to over-trust it. That is exactly why this class of issue survives design reviews and slows incident response.

Hybrid asymmetry becomes easier to misunderstand

If teams assume a visible propagated route still governs both directions of traffic, they can misread asymmetric behaviour as a gateway fault or application issue when the underlying problem is that forwarding authority has shifted.

Prefix learning and forwarding authority can diverge cleanly

This is worth stating plainly: a propagated route does not need to disappear for its practical authority to be reduced. Azure can still learn the prefix while VNRA governs the realised packet path.

Best Practices

Treat propagated routes as learned reachability, not guaranteed authority

In VNRA-connected hybrid designs, a propagated route should be treated as evidence that Azure knows the prefix exists, not proof that the gateway still governs packet forwarding for that path.

Validate routing at the subnet-path level

Do not validate “hybrid routing” as a broad topology property. Validate whether a given subnet’s traffic to a given prefix still behaves according to the route authority you expect.

Update your runbooks to separate control-plane and forwarding checks

Runbooks should explicitly distinguish between:

route learned
route visible
route authoritative for forwarding

Those are no longer interchangeable conditions.

Use effective routes as a clue, not a verdict

Effective routes are still useful. They are just not the final word in VNRA scenarios.

🍺

Brewed Insight: A visible VirtualNetworkGateway route can tell you Azure learned the prefix. It cannot, by itself, tell you the gateway still governs delivery once VNRA is shaping the path. In hybrid Azure, that is the difference between a route table that looks right and a system that actually behaves right.

Learn More

When Your UDR Stops Driving: VNRA, Override, and Routing Ambiguity

Tue, 07 Jul 2026 00:00:00 +1000

You attach a User Defined Route (UDR) to a subnet, point it at a next hop, and assume the path is now controlled.

That assumption is comfortable because it makes routing reviewable. It gives architects something concrete to approve, and operators something visible to inspect. But once Azure Virtual Network Routing Appliance (VNRA) is part of the design, that comfort starts to drift away.

The route may still be there. It may still be effective. It may still be selected. None of that, by itself, proves the packet followed the path you thought you enforced.

That is the real design shift here. VNRA does not simply add another routing feature. It changes what a UDR is good for. In VNRA-influenced environments, a subnet UDR should not be treated as proof of enforced path compliance. It proves declared routing intent only.

If the previous post was about route precedence as a decision model, this one is about what happens when route selection still looks fine but path certainty is gone.

The Mental Model

The common enterprise assumption is simple:

If I define the right UDR and attach it to the right subnet, I control where the packet goes next.

That sounds reasonable because it is often good enough in simpler Azure routing scenarios. A route is selected, a next hop is visible, and the design appears deterministic.

The problem is that engineers often treat a selected route as the same thing as an enforced packet path.

With VNRA, that is no longer a safe shortcut.

A UDR still expresses routing intent. Azure still evaluates effective routes. But the presence of VNRA means route declaration and forwarding proof are no longer the same class of evidence. The route table tells you what the control plane intends to do. It does not automatically prove the data plane behaved the same way.

How would this change something you design, deploy, or operate? It means a route table attached to a subnet is no longer enough to prove that a traffic policy is being enforced. For any path that matters operationally, you need both control-plane evidence and data-plane evidence.

How It Really Works

This post deliberately avoids re-teaching UDRs or repeating precedence rules from the previous entry. The important point here is narrower: VNRA weakens the assumption that explicit next-hop configuration is sufficient proof of actual packet steering.

There are three useful patterns to think about.

Cooperation

This is the easy case.

The UDR is selected, the configured next hop aligns with the expected forwarding path, and observed traffic behaviour matches the design. VNRA is present, but it does not introduce visible ambiguity for that flow.

Architects tend to assume this is the normal state because it is the least surprising. Sometimes it is.

Override

This is the case that matters most.

The UDR can still appear in the effective route set and still represent the declared next hop, yet that alone does not prove the reviewed path is the one the workload actually used. In VNRA-influenced designs, route selection can remain visible while forwarding certainty does not.

That is the key distinction advanced teams need to internalise: a route can still be valid, selected, and operationally insufficient as proof.

Conflict

This is where the design becomes brittle.

You now have more than one control model claiming authority:

the subnet UDR expresses explicit next-hop intent
the VNRA-influenced forwarding path shapes actual packet movement

At that point, your architecture stops being deterministic by inspection. Different engineers can read the same route design and reach different conclusions about what the packet will do. That is not a documentation issue. It is a design issue.

The Position to Be Clear About

In a VNRA-influenced environment, a subnet UDR should not be treated as proof of enforced path compliance.

It proves declared routing intent only.

That does not make the UDR useless. It still matters. It still participates in route selection. It still expresses a design decision that Azure takes into account. But if your architecture, audit process, or operational runbook assumes the route table alone proves where critical traffic went, your assurance model is weaker than you think.

That is the opinion this post is arguing for, and it is worth stating plainly because many enterprise networking standards still assume the opposite.

What Counts as Proof Now

Once VNRA is in play, the minimum proof standard needs to change.

For any path that matters for segmentation, compliance, resilience, or operational control, minimum acceptable proof should include:

control-plane evidence, such as effective route inspection
data-plane evidence, such as synthetic path testing, flow observation, or packet capture from representative workloads

That is the practical line.

If you have only reviewed the route table, you have reviewed intent. If you have observed the path from the originating subnet, you have started to prove behaviour.

That distinction should change both design review and incident response.

Where UDR Intent Starts to Break Down

Explicit next hop is no longer exclusive authority

A route pointing at a virtual appliance still declares a preferred next hop. That has not changed.

What has changed is the confidence you can place in that declaration as the final word. In VNRA scenarios, an explicit next hop is part of the forwarding story, not necessarily the whole story.

For platform teams, that means “we set the next hop” is not the same claim as “we proved the path”.

Effective routes remain useful, but no longer decisive

Effective route views still matter. You should absolutely keep using them.

But they now belong in the category of necessary evidence, not sufficient evidence. An effective route can confirm that Azure selected the UDR as part of the routing decision. It cannot, on its own, prove that the observed packet path still matches the reviewed design intent.

That is a subtle but important downgrade in what effective route inspection can tell you operationally.

Subnet-level standardisation creates confidence that may not be deserved

Enterprise landing zones often rely on shared route tables attached at subnet boundaries. This is attractive because it centralises control and keeps intent visible.

VNRA complicates that model. A shared route table can still standardise declared routing intent across workloads, but it no longer guarantees that the route table fully explains practical forwarding outcomes. In other words, standardised route declaration does not automatically mean standardised packet behaviour.

That matters most in estates where central networking teams treat route ownership as equivalent to path ownership.

Visualising the Difference

The classic mental model looks like this:

flowchart LR A[Workload Subnet] --> B[UDR Selected] B --> C[Configured Next Hop] C --> D[Assumed Packet Path]

That model is simple, inspectable, and increasingly incomplete.

A VNRA-aware model looks more like this:

flowchart LR A[Workload Subnet] --> B[Effective Route Selection] B --> C[Declared UDR Next Hop] C --> D[Azure Forwarding Behaviour] D --> E[Observed Packet Path] B -. Control-plane evidence .-> C D -. Data-plane reality .-> E

The important change is not that the UDR disappears. It is that the UDR stops being enough.

Real-World Impact

Design impact

Design standards that say “traffic from subnet X must traverse path Y” need a stronger proof model if VNRA is involved.

A UDR attached to subnet X is no longer sufficient evidence of enforcement. At best, it is evidence that the design intends to steer traffic towards path Y. If that path matters, the design should also define how the forwarding result will be validated.

That changes architecture review materially. Route declaration alone should not be accepted as path compliance evidence in VNRA-influenced designs.

Operational impact

Troubleshooting needs to split into two questions:

What route did Azure select?
What path did the packet actually take?

If you collapse those into one question, you will misdiagnose problems.

This is the practical workflow shift. Effective routes remain a starting point, but if route selection and observed behaviour disagree, that disagreement is not noise. It is the signal.

Governance impact

Many organisations still review route tables as if they prove policy enforcement.

In VNRA scenarios, that review model is incomplete. Route tables prove declared intent, not necessarily behavioural compliance. If audit, architecture, or change control processes are certifying path enforcement based solely on subnet UDRs, they are approving configuration, not proving outcome.

That is not just a networking detail. It is a control weakness.

Reliability impact

Ambiguous path authority is dangerous during incidents.

When a path fails cleanly, rollback is usually straightforward. When a path is only partially explained by the route configuration, every incident takes longer because engineers are trying to reconcile two truths:

the route table says one thing
the packet behaviour suggests another

That slows containment, weakens fault isolation, and makes “safe” changes less safe than they look.

Implementation Artefact

This series deliberately avoids deployment walkthroughs, and that matters here.

A UDR declaration artefact on its own is not especially useful in this post because route configuration is not the disputed part of the argument. The contested issue is whether route declaration proves forwarding behaviour. Showing Bicep or CLI to create a route table would add configuration detail without adding confidence to the thesis, so it is intentionally omitted.

The more useful operational artefact is a validation mindset: pair route inspection with an observable data-plane check from the workload context you actually care about.

If you need a shorthand test for design review, use this:

If we have only inspected the effective route, we have verified intent. If we have also observed the path from the originating subnet, we have started to verify enforcement.

That is the artefact that should survive into production operations.

Patterns That Create Ambiguity

“We own the route table, so we own the path”

This is a control-plane assumption, not a proven operational truth.

If VNRA can influence forwarding outcomes beyond what the route table alone proves, route ownership and path ownership are no longer the same thing.

“The effective route is correct, so the issue must be somewhere else”

That is often where advanced teams lose time.

The effective route may be correct in the narrow sense that Azure selected the expected route. That still does not settle whether the reviewed path assumption survived contact with the data plane.

“Adding a UDR makes the design more deterministic”

Sometimes it does.

But in VNRA-influenced topologies, adding a UDR can also create a second explanation for path behaviour without eliminating the first. That is not increased determinism. It is layered intent.

If the environment cannot clearly tell you which layer is authoritative for a given flow, the design is less deterministic than it was before.

Gotchas & Edge Cases

The platform may not give you a dramatic failure signal

The awkward scenarios are not always the ones where Azure rejects a route or reports an obvious fault.

The more dangerous case is where the UDR remains present, valid, and reviewable, while operators assume that means the packet path is proven. The hazard is false certainty, not visible breakage.

Symmetry should be validated, not assumed

Even if the forward-path evidence looks clean, do not assume the return path is governed by the same logic. Once multiple routing influences exist, symmetry becomes an operational claim that needs proof.

Detailed return-path analysis is out of scope here, but this is one of the first places ambiguous routing authority tends to surface.

Shared route tables can hide confidence gaps

A common route table applied to multiple workloads can create the impression that path behaviour is equally understood for all of them.

That may be true at the level of declared intent. It is not automatically true at the level of observed forwarding.

Best Practices

1. Stop treating subnet UDRs as path enforcement evidence

In VNRA-influenced environments, a UDR is evidence of intent. Treating it as proof of enforcement is the mistake.

2. Define a proof standard for critical paths

If a traffic path matters, decide in advance what evidence counts. A good minimum standard is effective route inspection plus at least one data-plane validation method from a representative source.

3. Separate route review from path assurance

Architecture review can approve declared intent. Operational validation should prove actual behaviour. Those are related, but they are not the same control.

4. Use disagreement as a trigger, not an anomaly

If the route view looks right but the path looks wrong, do not treat that as an edge case to investigate later. Treat it as a primary indicator that your model of forwarding authority is incomplete.

5. Reject ambiguous designs early

If a design requires too much explanation to answer “who really controls this packet path?”, it will be worse under incident pressure. Ambiguity is not sophistication.

🍺

Brewed Insight: UDRs still matter with VNRA, but they are no longer sufficient evidence of deterministic packet steering. If you have only inspected the route table, you have reviewed intent; if you have observed the path, you have started to prove reality.

Learn More

When Routes Disagree: VNRA Precedence and Conflict Resolution in Azure

Thu, 02 Jul 2026 00:00:00 +1000

If you have ever looked at an Azure effective route table and thought, that should not be the route that wins, this is the part that matters.

Route precedence in Azure is often explained as if each routing feature gets a turn at being authoritative. System routes do the baseline work, BGP propagated routes inject dynamic reachability, User Defined Routes (UDRs) override intent, and VNRA somehow arrives as a new control point that sits above the rest.

That framing is convenient. It is also what causes people to misread packet paths.

The stronger and more useful position is this:

VNRA is not a separate precedence domain. It changes routing outcomes inside Azure’s existing route selection logic, and the only version that matters is the effective route behaviour seen by the workload NIC.

That changes something you design and operate straight away. You stop asking whether VNRA “wins” against UDRs, BGP, or system routes as if it were a fourth referee. Instead, you ask what prefixes are present, which route source owns the winning prefix, and what next hop is actually selected for the packet.

That is the difference between platform intent and data-plane truth.

The Mental Model

The common assumption is that Azure routing is layered by feature:

system routes are default behaviour
propagated routes add learned reachability
UDRs override platform defaults
VNRA adds a new routing authority on top

That model breaks because Azure does not forward packets based on feature hierarchy. It forwards packets based on the effective route selected for a destination from the source NIC.

VNRA matters, but not because it suspends the normal rules. It matters because it affects the set of candidate routes and next-hop outcomes that Azure can realise. Once those candidates exist, Azure still resolves forwarding the same way it always has:

longest prefix match first
route source precedence only when prefixes are equal
the selected route becomes the packet path

So the mental shift is simple:

VNRA should be treated as a routing outcome modifier visible through effective route behaviour, not as a separate precedence domain.

If you treat it as a special layer above the rest, you will keep looking for feature interactions when the real answer is usually just prefix specificity plus route source precedence.

How It Really Works

Azure route selection is less mysterious when you strip it back to packet behaviour.

For any destination, Azure evaluates the effective route set applied to the source interface. The decision process is straightforward:

Find all matching routes for the destination IP
Select the most specific prefix
If multiple routes have the same prefix length, apply route source precedence
Use the winning route’s next hop

That means the first real question is never which routing feature is in charge. It is:

Which route actually wins for this prefix on this NIC?

That sounds obvious, but it gets lost quickly once VNRA enters the conversation. Engineers start attributing precedence to the feature rather than to the route that became effective.

A data-plane view of route selection

flowchart TD A[Packet arrives at source NIC] --> B[Match destination against effective routes] B --> C{Matching routes exist?} C -->|No| D[No explicit match beyond platform defaults] C -->|Yes| E[Select longest prefix match] E --> F{Equal prefix candidates remain?} F -->|No| G[Use selected next hop] F -->|Yes| H[Apply route source precedence] H --> I[Install winning route as forwarding decision] I --> G

The key point is deliberately plain: VNRA does not replace this logic. It shows up through it.

Route Source Conflicts in Practice

The route sources involved are not new, even if the design looks new.

System routes

System routes are Azure’s built-in opinion about reachability. They remain valid until something more specific exists, or an equal-prefix route with higher precedence takes their place.

The mistake is to treat them as irrelevant once you start using VNRA. They are still part of the candidate set, and they still win whenever nothing more specific or higher-precedence applies.

Propagated routes

BGP propagated routes can override system routes for the same prefix. They do not override a more specific route from another source, and they do not outrank a UDR for an equal prefix.

This is where people often start blaming VNRA for inconsistency when the real cause is simpler: a propagated route exists for a narrower prefix than the summarised path they expected to carry appliance-bound traffic.

UDRs

UDRs are still the clearest way to impose routing intent for a specific prefix. For equal prefixes, a UDR takes precedence over propagated and system routes.

That does not make UDRs universally dominant. A broad UDR only controls traffic where no more specific route exists. If you define a default route or a large summary and then allow narrower prefixes to appear from another source, Azure will choose the narrower route every time.

That is not an exception. That is the design consequence of using broad routing intent.

Where VNRA fits

This is the line to stay disciplined on:

VNRA does not appear as a separate route-precedence layer that overrides Azure routing rules. Its impact is expressed through the effective routes and next-hop decisions Azure realises.

So when engineers say “VNRA overrode my route”, what they usually mean is one of four things:

a more specific route existed than the one they expected to drive traffic through the appliance
an equal-prefix route with higher precedence was effective
the route they expected was configured, but not the route selected
they were reasoning from design intent, not from the effective route table on the workload NIC

That is not semantics. It is the operational difference between understanding Azure routing and narrating it.

What Actually Creates Ambiguity

Here is the harder opinion this topic needs.

VNRA does not introduce routing ambiguity. Overlapping prefixes and poor route intent do. VNRA just makes that ambiguity harder to ignore.

That matters because a lot of post-deployment confusion gets framed as platform inconsistency when it is really unresolved routing intent:

broad appliance steering is expected to cover everything
narrower prefixes are introduced later by propagation or platform behaviour
traffic follows the narrower route
the team concludes VNRA is unpredictable

But the route selection was predictable. The design was not precise enough.

If you want deterministic packet paths, your prefixes need to be deterministic. VNRA cannot rescue vague routing intent.

Real-World Impact

This changes how you assess routing risk.

Reliability

A route conflict does not need to cause packet loss to be a problem. If traffic takes a path other than the one assumed by the design, reliability becomes conditional. The system may work until a dependency expects inspection, symmetry, or path locality that is no longer true.

Security

If your security model depends on traffic traversing an appliance path, broad route intent is not enough. Any more specific competing route can bypass that path without creating a visible outage.

That means inspection assumptions are only as strong as your prefix discipline.

Scalability

The larger the environment, the more likely it is that summarised intent and specific reachability will collide. VNRA does not make large environments harder to reason about by itself. It exposes where the routing model was already under-specified.

Operational clarity

The practical question remains:

How would this change something I design, deploy, or operate?

It means you validate routing by effective outcome, not by feature configuration. And it means broad steering constructs should be treated as coarse guidance unless you have actively controlled competing specific prefixes.

Implementation Example

This post is not a deployment guide, but precedence claims need a concrete artefact. The right artefact here is the effective route table, because that is where Azure shows the realised forwarding candidates.

Azure CLI: inspect effective routes on a NIC

1
2
3
4


az network nic show-effective-route-table \
 --resource-group rg-network-prod \
 --name nic-app-01 \
 --output table

For this topic, the fields that matter are:

destination prefix
route source
next hop type
next hop IP, where applicable

If your routing argument is not visible there, it is not yet a data-plane argument.

Example conflict

Assume the effective route table contains the following entries:

Source	Prefix	Next Hop Type	Next Hop
Default	10.20.0.0/16	Virtual network	-
VirtualNetworkGateway	10.20.10.0/24	Virtual network gateway	-
User	10.20.0.0/16	Virtual appliance	10.0.1.4
User	0.0.0.0/0	Virtual appliance	10.0.1.4

Now apply packet logic.

Traffic to 10.20.10.7 follows the /24 propagated route because it is the most specific match
Traffic to 10.20.50.9 follows the /16 UDR because it is an equal-prefix conflict with the system route and the UDR has higher precedence
Traffic to 8.8.8.8 follows the 0.0.0.0/0 UDR unless a more specific route exists

None of those outcomes require a special VNRA rule. They only require Azure to apply normal route selection.

Deterministic vs Non-Deterministic Outcomes

This distinction needs to be blunt.

Azure route selection is deterministic once the effective route set is realised. The non-determinism people experience is usually in route convergence, propagation timing, or control-plane state visibility not in the precedence engine itself.

That is an important separation.

If the same NIC has the same effective routes and the same destination, Azure should produce the same forwarding decision. If the observed behaviour changes over time, the first suspicion should be changing route state, not changing precedence logic.

In VNRA discussions, that matters because people often attribute temporary inconsistency to the feature when they are really observing asynchronous route realisation.

That does not make the problem trivial. It just means the problem is different.

Gotchas & Edge Cases

Broad appliance steering does not guarantee universal appliance transit

A default route or summary route pointing to an appliance only governs traffic where no narrower match exists. If you need deterministic inspection for a destination set, summarised intent alone is weak control.

Route presence is not route selection

A route being present in the effective route table does not mean it is the route used for your destination. It only means it is a candidate.

Equal-prefix reasoning is often skipped too early

Engineers jump to route source precedence before checking whether the conflicting routes even have equal prefixes. Most disputes disappear once you compare prefix length honestly.

VNRA can be blamed for decisions it did not make

If the winning path is the result of a more specific propagated route or an equal-prefix UDR, the routing logic is doing exactly what Azure normally does. VNRA may be involved in the design, but not in the precedence mechanism.

Best Practices

Design routing intent at the prefix level

Do not ask whether VNRA should “take precedence”. Ask which exact prefixes must be controlled, and what other sources may advertise or inject overlapping routes.

Treat broad routes as coarse policy, not hard enforcement

A summary or default route gives directional intent. It does not prove exclusive path ownership.

Validate from the workload NIC

Configured route tables tell you what you meant. Effective routes tell you what Azure is prepared to do. For conflict resolution, only the latter settles the question.

Call overlapping prefixes what they are

If two routing sources are competing for the same traffic set because the prefix model is sloppy, that is not platform complexity. It is unresolved design intent.

🍺

Brewed Insight: Most “VNRA routing surprises” are not VNRA surprises at all. They are ordinary Azure route selection rules exposing a design that relied on broad intent where specific control was required.

Learn More

Azure Virtual Network Routing Appliance: When Packet Truth Moves Away from the Edge

Tue, 30 Jun 2026 00:00:00 +1000

In plain Azure networking, plenty of engineers get away with a simple habit: check the effective routes on the NIC, sanity-check the subnet, and infer the packet path from there.

Most of the time, that shortcut is good enough.

VNRA is where it starts to break.

Not because Azure suddenly becomes opaque, and not because route evaluation stops mattering. The change is more useful than that. Once VNRA is introduced, the packet path is no longer best understood from the edge inward. The centre of gravity moves. Forwarding intent becomes more centralised, and attachment-level effective routes become a local view of a broader forwarding design.

That is the shift this post is about.

The Mental Model

The common assumption is straightforward:

If I can see the effective routes on the NIC or subnet, I can explain how the packet will move.

That assumption holds often enough in Azure to become muscle memory. It is also exactly the habit VNRA exposes.

The better mental model is this:

VNRA does not replace Azure routing. It recentres forwarding intent around a shared routing control point, which means NIC- and subnet-level effective routes are no longer the authoritative explanation of end-to-end packet behaviour.

That is an important distinction.

This is not about obscurity. Azure has not become mysterious. System routes still exist. User-defined routes (UDRs) still matter. Route precedence still matters. Longest prefix match still matters.

What changes is where packet truth lives.

Before VNRA, many engineers reason from the edge inward:

inspect the source attachment
read the effective routes
infer the path

With VNRA in the design, that shortcut becomes unreliable. You now need to reason from the forwarding design outward:

understand the role of the shared routing control point
then interpret local effective routes in that context

That is a design shift, an operations shift, and a troubleshooting shift.

How It Really Works

VNRA does not turn Azure into a traditional routed fabric with a core router that owns the whole network. Azure still owns the underlying virtual network fabric. The platform still provides system behaviour. Effective routes still express local route-selection context.

What changes is that forwarding expectations increasingly need to be interpreted relative to VNRA’s role in the path.

That makes VNRA less like a simple next-hop override and more like the logical centre of forwarding intent.

Before VNRA

In a conventional Azure design, an engineer might look at the source NIC, inspect its effective routes, and treat that as a near-final explanation of packet behaviour.

That is not perfectly complete, but it is often operationally serviceable.

A familiar mental flow looks like this:

flowchart LR A[Source NIC] --> B[Effective route evaluation] B --> C[Winning route selected] C --> D[Azure native forwarding path] D --> E[Destination]

After VNRA

With VNRA present, the route evaluation at the source still matters, but it no longer tells the whole story on its own. The winning route needs to be interpreted in the context of a forwarding design whose centre now sits at the routing appliance.

flowchart TB subgraph SpokeA[Spoke A] A1[Source workload] A2[Source NIC effective routes] end subgraph Hub[Shared routing domain] H1[VNRA as forwarding control point] end subgraph SpokeB[Spoke B] B1[Destination workload] end A1 --> A2 A2 --> H1 H1 --> B1

The point is not that Azure stops selecting routes at the source. It does not.

The point is that the source attachment no longer gives you a sufficient explanation of the full packet path. It gives you a local route-selection view inside a forwarding design that now has a more central control point.

A Concrete Scenario: Spoke-to-Spoke Traffic

This is where the old instinct starts to fail.

Assume you have:

a workload in Spoke A
a workload in Spoke B
VNRA positioned in the shared routing domain
traffic between the spokes expected to follow that central forwarding design

An engineer checks the effective routes on the source NIC in Spoke A and sees the expected destination prefix. That is useful, but it only answers part of the question.

It tells you:

what route-selection context exists at the source attachment
which route is likely to win locally

It does not, by itself, prove that the end-to-end packet path is correctly understood purely from that edge view.

That is the mistake to avoid.

In a VNRA-centred design, the source NIC route table is no longer the best place to infer the whole story. The authoritative interpretation now sits with the shared forwarding design that the appliance represents.

So the practical shift is this:

pre-VNRA habit: read the packet path from the source edge
VNRA-aware habit: read the packet path from the forwarding centre, then use edge effective routes to validate local context

That is a very different troubleshooting posture.

What Changes in Effective Routes

This is where precision matters.

The change is not that effective routes become wrong.

The change is not that Azure starts hiding route information.

The change is this:

Effective routes remain useful for understanding local route-selection context, but they are no longer sufficient on their own to explain end-to-end packet behaviour once VNRA becomes the logical centre of forwarding intent.

That is a narrower and more defensible claim.

What still holds

Longest prefix match still applies.
Route precedence still applies.
UDRs still influence forwarding intent.
System routes still exist.
Propagated routes still matter where applicable.

What changes operationally

A familiar-looking effective route table can create false confidence.
Local route correctness does not guarantee correct packet-path interpretation.
The packet path can no longer be safely inferred from attachment-level visibility alone.
Route inspection becomes one step in analysis, not the final answer.

That is the real impact.

Azure Default Routing Behaviour Does Not Disappear

One easy mistake is to overstate what VNRA changes.

VNRA does not mean Azure abandons its default routing model. The platform is still doing what the platform does. Azure has not become a blank underlay underneath your appliance.

That matters because this is not an article arguing that VNRA replaces Azure routing.

It is arguing something more specific:

VNRA changes the operational locus of truth for packet-path interpretation.

That is why engineers get caught.

They compare route objects before and after VNRA, see something broadly familiar, and conclude the forwarding story is still edge-readable in the same way. It often is not.

The route constructs may still look recognisable. The packet-path explanation is what changes.

Why Next-Hop Thinking Is Not Enough

A lot of Azure route interpretation compresses two ideas into one:

which route wins
what packet path that creates

Without VNRA, that shortcut often survives.

With VNRA, it becomes much less safe.

The route winner at the source attachment still matters, but the realised forwarding expectation now needs to be interpreted relative to the appliance-centred design. If you skip that second step, you can end up with a route table that looks correct and an understanding of packet behaviour that is not.

That is why this topic matters in production.

Real-World Impact

So how would this change something you design, deploy, or operate?

It changes where you validate packet truth.

Design

When VNRA is in the forwarding design, you should stop validating routing solely from the edge.

Instead, design reviews need to ask:

what is the intended central forwarding path?
which flows depend on that shared routing control point?
do local effective routes support that intent, rather than supposedly define it?

That sounds subtle, but it changes how deterministic your design really is.

A route table can be technically correct and still be a poor explanation of the intended packet path.

Deployment

Successful deployment is no longer proven by:

a route object being present
an effective route appearing on a NIC
an appliance existing in the environment

Those are useful checks, not sufficient proof.

If VNRA is the centre of forwarding intent, deployment validation has to confirm that the intended traffic classes actually align with that central design. Otherwise you have validated configuration artefacts, not forwarding behaviour.

Operations

This is where the change becomes most visible.

Your runbooks need to separate two different questions:

Is local route selection at the attachment point correct?
Is the packet path behaving according to the VNRA-centred forwarding design?

Those are not the same question.

Without that distinction, teams end up diagnosing packet-path issues as though they were route-precedence issues, or vice versa.

That is how incident response gets slower and less accurate.

Implementation Example: Effective Routes as Local Evidence

The Azure CLI still gives you a useful first view.

1
2
3


az network nic show-effective-route-table \
 --resource-group rg-network-prod \
 --name spokea-app01-nic

That output tells you the local route-selection context for that NIC.

It does not by itself prove the full end-to-end path once VNRA is acting as the shared routing control point.

A VNRA-aware interpretation looks more like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Source NIC effective routes:
- 10.20.0.0/16 via VirtualNetwork
- 10.30.0.0/16 via UserDefinedRoute

What this tells you:
- The source attachment has a visible route-selection context.
- A specific route source is winning locally.

What this does not tell you on its own:
- That the full packet path is correctly understood purely from this edge view.
- That the observed forwarding behaviour aligns with the VNRA-centred design.

That is the practical shift. The command has not changed. The meaning you assign to its output has.

Gotchas and Edge Cases

Familiar route output creates false confidence

This is probably the biggest trap.

The effective route table can look entirely reasonable while still being an incomplete explanation of actual packet behaviour. Engineers trust familiar output quickly. VNRA punishes that habit.

Local route correctness and path correctness are different things

You can have a locally sensible route outcome and still misread the real packet path if you are treating the source attachment as the authoritative viewpoint.

That matters most when traffic between shared network domains is expected to conform to a centrally expressed forwarding design.

Comparing before and after route tables can mislead you

If your only test is “did the effective route entries visibly change?”, you may miss the actual shift.

VNRA is often less about inventing new-looking route artefacts and more about changing where the authoritative packet-path interpretation now sits.

Split responsibility makes diagnosis worse

If one team validates route objects and another validates appliance health, but neither owns packet-path interpretation end to end, VNRA will expose that gap quickly.

This is not a governance post, so I will leave it there. Operationally, though, the boundary matters.

Best Practices

1. Stop treating edge effective routes as the whole packet narrative

They are still useful. They are no longer authoritative on their own.

2. Model packet paths from the forwarding centre outward

If VNRA sits at the heart of forwarding intent, start there. Then use attachment-level route views to confirm local context.

3. Separate route correctness from forwarding correctness in your runbooks

Make this explicit. It will prevent a lot of bad diagnosis during incidents.

4. Challenge designs that rely on edge inference alone

If the only way to explain a path is by reading local route tables and hoping that tells the whole story, the design is probably under-validated.

5. Favour determinism over cleverness

A VNRA-centred design should make packet intent clearer, not turn troubleshooting into guesswork.

🍺

Brewed Insight: VNRA is not interesting because it adds another routing target. It is interesting because it moves packet truth away from the edge. Once forwarding intent is centralised, effective routes become local evidence, not the final explanation.

Learn More

Designing Private Connectivity for Adversarial Conditions

Tue, 23 Jun 2026 00:00:00 +1000

A Private Endpoint can make an architecture diagram look safer in the same way a locked internal door feels safer than one opening onto the street.

That feeling is not meaningless, but it is easy to over-trust.

In this series, we have already established that Private Endpoint changes exposure, not the existence of attack surface. This post takes the next step: what should you actually do with that idea when you are designing private connectivity for production environments that will drift, fail, and eventually contain something you did not intend to trust?

Because that is the real design question.

Not whether a service is private.

Whether the private path remains safe when something on the inside is already wrong.

That should change something you design, deploy, and operate. It should push you away from treating private connectivity as a security outcome, and towards treating it as a dependency chain that must be intentionally constrained.

The Mental Model

The common assumption is simple:

If the PaaS service is reachable only through a Private Endpoint, then the network has meaningfully reduced trust risk.

That assumption breaks because “private” is doing too much work.

Private Endpoint reduces one category of exposure: public network reachability. That can be useful. It can remove accidental internet exposure, reduce opportunistic scanning, and simplify some perimeter decisions.

But none of that means the resulting private path is trustworthy.

A Private Endpoint does not assert that the calling workload is legitimate. It does not prove the caller came from the application you expected. It does not make private DNS authoritative in a security sense. It does not prevent an internal foothold from using the same route you built for valid traffic.

The dangerous shift is not technical. It is psychological.

Teams move from:

“this service is exposed, so we need to control access carefully”

to:

“this service is private, so the network is already doing most of the work”

That is how implicit trust gets introduced. Quietly, incrementally, and usually in the name of convenience.

How It Really Works

Private connectivity to Azure PaaS is not one control. It is a chain of dependencies.

That chain usually includes:

a client resolving the service name to a private address rather than the public endpoint
network reachability from the source workload to the Private Endpoint path
control-plane permissions that determine who can create, approve, modify, or redirect that path
service-side authentication and authorisation that still decide what the caller can actually do
operational processes that govern how changes to any of those dependencies are reviewed

That is the thing you are really designing.

flowchart LR A[Workload] --> B[DNS Resolution] B --> C[Private IP for PaaS Service] C --> D[Routing and Reachability] D --> E[Private Endpoint Path] E --> F[Azure PaaS Service] F --> G[Service-side Authorisation] H[Control Plane Permissions] --> B H --> E H --> F

The point is not that the chain is complicated. The point is that a lot of trust gets smuggled into the environment through dependencies that are often treated as plumbing.

Three of those dependencies matter most.

DNS becomes security-significant

Private DNS is not just a convenience layer once it starts steering clients towards sensitive internal service paths.

If a network can resolve a service name to a Private Endpoint address, it has gained internal knowledge and possibly internal reachability. If that resolution scope is broader than the set of intended consumers, you have expanded trust whether you meant to or not.

DNS is not the security boundary. But it absolutely becomes part of the exposure model.

Reachability becomes a privilege

A route to a Private Endpoint is not neutral plumbing. It is permission to attempt access.

Whether the service ultimately accepts the request depends on other controls, but broad reachability still expands the attack surface around that service. If too many internal networks can get there, too many internal workloads can participate in probing, misuse, and lateral movement.

Private does not mean narrow.

Control-plane authority shapes data-plane exposure

Who can approve a Private Endpoint? Who can link a private DNS zone? Who can alter the target service configuration in a way that changes effective exposure?

Those are not background administrative concerns. They define who can reshape the trust path.

If the same operational boundary can create the path, advertise the path, and widen the path without meaningful review, then the design is not just technically permissive. It is organisationally permissive.

Designing for Adversarial Conditions

If you accept that private connectivity is hostile-adjacent, the design objective changes.

You are no longer trying to make access private in the abstract. You are trying to make private access:

explicitly bounded
hard to repurpose
easy to review
observable when misused
survivable when internal assumptions fail

That means designing against abuse, not just designing for successful application traffic.

Trust Boundaries Need to Be Declared, Not Inferred

One of the more persistent design mistakes with Private Endpoint is that teams describe connectivity as though it explains trust.

They say things like:

the app subnet can access the database privately
the spoke can reach storage over Private Link
the service is internal-only now

None of those statements define a trust boundary. They describe a route.

A trust boundary around private PaaS access usually spans several things at once:

the specific workloads expected to initiate the connection
the network scopes from which they are allowed to do so
the DNS path that makes the service discoverable
the service-side identity and authorisation model
the administrative scope allowed to change any of the above

If those conditions are not explicit, the trust boundary is not explicit.

How would this change something you design, deploy, or operate?

It means a Private Endpoint should not pass design review simply because the service no longer has public access. It should only pass if the intended consumers, resolution scope, reachability scope, and change authority are all named and defensible.

Broad DNS Linkage Is Not a Neutral Convenience Choice

This is the pattern the article is prepared to reject outright.

If private DNS zones are linked broadly to shared or inherited network scopes by default, the design should be treated as over-trusting until proven otherwise.

That is not just an operational shortcut. It is an expansion of internal trust.

The reason is simple. Broad private DNS linkage does at least two things:

it widens internal service discovery
it often widens effective access assumptions, even where service-side controls still exist

That means “link it everywhere for simplicity” is not a harmless design preference. It is a decision to make the private path discoverable by more of the environment than may actually need it.

For adversarial design, that should fail review unless the broader scope is explicitly justified.

This is one of the most common places where Private Endpoint quietly shifts from “reduced public exposure” to “expanded internal trust surface”.

Inherited Reachability Is Not a Trust Decision

A second pattern worth rejecting is inherited reachability through convenience peering, shared transit assumptions, or broad east-west connectivity.

If a workload can reach a Private Endpoint mainly because the network topology made it easy, the design is incomplete.

Convenience routing is not a trust decision.

This matters because many estates end up with exactly this shape:

a central or shared network hosts the resolution path
peered networks inherit access expectations
workloads well outside the original design scope can now resolve or reach the endpoint
nobody can clearly say whether that exposure is intentional

That is not a mature private connectivity design. That is ambient access.

Private Endpoint should narrow consumer scope, not quietly rely on whichever networks happen to already be connected.

Control-Plane Concentration Should Be Treated as Abuse-Prone

A lot of technical reviews focus only on where packets flow.

That is not enough.

If one operational boundary can:

create the Private Endpoint
advertise it through DNS
and alter target service exposure

without independent review, the design should be treated as abuse-prone.

That does not mean every environment needs elaborate bureaucracy. It means concentrated change authority is part of the threat model. A private path is easier to trust than to continuously validate, and that is exactly why control-plane concentration matters.

This is often missed because it does not show up in architecture diagrams. But in production estates, the ability to reshape a trust path is often as important as the path itself.

Design Review Tests

The quickest way to improve Private Endpoint designs is to stop describing them as “best practice” and start evaluating them as review decisions.

The table below is intentionally opinionated. It is not a reference architecture. It is a set of cues for deciding whether risk is being constrained or merely relocated.

Design condition	Operationally convenient	Adversarially sound	Review outcome
Private DNS linked broadly across shared or inherited VNets	High	Low	Reject unless consumer scope is explicitly justified
Private Endpoint reachable through general peering convenience rather than named consumer scope	High	Low	Reject unless reachability is intentionally constrained
Same team can create endpoint, manage DNS path, and change target service exposure without meaningful review	High	Low	Escalate for separation or compensating control
Only named consumer networks can resolve and reach the service path	Medium	High	Acceptable if monitoring and change review are in place
DNS scope is narrower than general platform connectivity and reviewed as a security dependency	Medium	High	Strong signal that trust is intentional

This is the practical shift the article is arguing for.

Do not ask only whether the service is private.

Ask whether the private path is narrow enough, reviewable enough, and observable enough to survive internal compromise.

Real-World Impact

This changes more than network diagrams.

It changes what should pass architecture review, what should trigger operational scrutiny, and what should be treated as a security-relevant platform change.

Design impact

You should stop accepting “private-only” as evidence that exposure is constrained. Consumer scope, DNS scope, reachability scope, and change authority all need to be explicit.

Operational impact

DNS links, Private Endpoint approvals, and route changes should be reviewed as trust-path changes, not background networking tasks.

Reliability impact

The more broadly the private path is shared, the more outages and emergency fixes tend to widen trust in the name of restoring service. Designs that rely on broad convenience are harder to tighten later.

Security impact

A compromised internal workload should not automatically inherit useful private access to sensitive PaaS resources just because it exists somewhere inside the estate.

If your design cannot make that claim with confidence, the risk is not constrained.

Implementation Artefact

This post intentionally omits deployment code.

That is deliberate.

The risk discussed here is not in how to create a Private Endpoint. It is in how broadly the trust path around that endpoint is allowed to exist. In this case, a design-review artefact is more useful than Bicep or CLI because the architectural failure mode is excessive implicit trust, not deployment complexity.

Gotchas & Edge Cases

Shared platforms often become shared trust zones

A workload platform may be centrally managed and still be multi-tenant in practice. If multiple application teams share compute, runtime, or network adjacency, “internal consumer” becomes a much weaker category than diagrams suggest.

Temporary troubleshooting access tends to outlive the incident

Emergency DNS links, broad peering changes, and “just for now” connectivity often survive long after the original problem has gone away. In adversarial terms, temporary convenience is one of the most common ways permanent trust expansion happens.

Private-only language hides weak consumer definition

If a team cannot name which workloads are supposed to consume the service, private connectivity is already too broad conceptually, even before the network proves it.

Best Practices

For this topic, best practice is less about using the right Azure feature and more about refusing weak trust assumptions.

Fail designs where discovery scope exceeds consumer scope

If more networks can resolve the service than are explicitly approved to consume it, the design is over-trusting.

Fail designs where reachability is inherited by convenience

If access exists because peering or shared routing made it easy, rather than because consumer scope was intentionally defined, the design is incomplete.

Treat DNS and Private Endpoint changes as exposure changes

Do not classify these as low-risk plumbing updates. They modify how internal trust is expressed.

Separate trust-path control, or compensate explicitly

If endpoint creation, DNS control, and target exposure sit inside one operational boundary, that should trigger either separation or a named review control. It should not be invisible.

Design for verification

A mature design should let you answer, without archaeology:

who can resolve this service
who can reach it
who can change that
how unexpected use would be noticed

If those answers depend on tribal knowledge, the design is weaker than it appears.

Indicators That Private Endpoint Risk Is Intentionally Constrained

Private Endpoint risk is being meaningfully constrained when most of the following are true:

the set of networks that can resolve the service is explicitly smaller than the general platform network scope
the set of workloads that can reach the service is intentionally defined rather than inherited
service-side authorisation remains mandatory and visible
control-plane authority over endpoint creation, DNS path, and target exposure is not casually concentrated
unexpected resolution, connection attempts, or path changes are observable
incident-driven access expansions are time-bound and reviewed out
architecture documentation names trust assumptions directly instead of implying that internal location is enough

If those conditions are absent, the environment may still be private, but it is not especially constrained.

🍺

Brewed Insight:

Private Endpoint is most dangerous when it removes just enough visible exposure to make everyone stop asking where trust went.

If your design relies on “internal networks” as the reason a PaaS service is safe to expose privately, you have not designed a trust boundary. You have named a location.

Learn More

Private Endpoint Sprawl and Shadow Access: When Private Starts Meaning Unseen

Thu, 18 Jun 2026 00:00:00 +1000

Private Endpoints often arrive with the sort of confidence that makes people stop asking second-order questions.

The first one is usually deliberate. A shared service needs to be consumed privately, the path is approved, DNS is wired up, and everyone feels like exposure has been reduced. Then another team needs access from a different virtual network. Then another environment gets its own endpoint. Then a migration leaves the old one behind. A year later, the architecture still looks private, but it is no longer especially clear.

That is the problem this post is really about.

Private Endpoint sprawl is not just untidy networking. It is the slow expansion of internal reachability to services that many teams still think of as tightly contained. The risk is not that Private Endpoints magically bypass identity or authorisation. The risk is that more internal footholds now inherit viable paths to high-value services, and defenders lose confidence that the approved path is the only path that matters.

That changes something you design, deploy, and operate. If a new Private Endpoint is treated as routine plumbing rather than as a new internal exposure point, your architecture can accumulate shadow access long before anyone notices.

The Mental Model

The common assumption goes something like this:

If a service is only reachable through Private Endpoints, exposure is reduced and control has improved.

That is true only while the private access paths remain deliberate, bounded, and visible.

What breaks the mental model is scale.

A Private Endpoint is not just a safer service setting. It is a new network presence for a platform service inside a virtual network you control imperfectly, with DNS and routing dependencies you may not fully own, and with trust implications that extend beyond the service team.

One endpoint is a design choice.

Several endpoints to the same service across different networks is no longer just connectivity. It is topology. And once those endpoints span different trust zones or administrative boundaries, it becomes security-relevant sprawl.

That is the shift worth holding onto:

Private Endpoint sprawl does not weaken identity controls by itself. It weakens your certainty about where sensitive services are reachable from after a compromise.

How It Really Works

Sprawl is rarely the result of one bad design meeting. It is usually the accumulation of locally reasonable decisions.

Teams create endpoints close to workloads

A workload team needs private access to a Key Vault, Storage Account, SQL Database, or Cosmos DB account owned elsewhere. Rather than consuming an already understood path or challenging the design, they create a new Private Endpoint in their own virtual network.

Technically, that may be fine.

Architecturally, the same shared service now has another private network presence in another part of the estate. That means another trust zone can originate traffic to it, another DNS context can resolve it privately, and another team now influences the effective exposure of the target service.

Service ownership and access-path ownership diverge

This is where the architecture starts to lie to you.

The service owner may still control the Key Vault or Storage Account itself, but they often do not control every network from which private access now exists. A sensitive service can look tightly governed from the resource perspective while being privately reachable from networks the service owner neither administers nor reviews regularly.

At that point, the exposure boundary is no longer defined only by the service configuration. It is also defined by every approved Private Endpoint connection and every network that hosts one.

DNS makes duplication easier to ignore

Private DNS does exactly what it is supposed to do: it makes the service name resolve in the right place without the application caring too much.

Operationally, that convenience can hide architectural drift.

Consumers continue to use the same name. Connections still work. The duplication disappears behind name resolution. Over time, the platform may end up with several private access paths to the same service across linked zones and virtual networks, but very few people can say with confidence where that service resolves privately and where it does not.

Old access paths tend to survive

Private Endpoints are easy to create and oddly persistent.

Migration endpoint? Left behind. Temporary analytics integration? Still there. Retired workload in a linked subscription? Endpoint survives. Replacement endpoint after a redesign? Old one never cleaned up.

This is where shadow access starts to matter. The network path still exists, the name may still resolve, and the target service is still privately reachable from a place that is no longer part of anyone’s active design intent.

A Simple View of Sprawl

flowchart LR subgraph SharedService["Shared Service Subscription"] KV["Key Vault"] SA["Storage Account"] end subgraph Prod["Prod Trust Zone"] PE1["PE to Key Vault"] PE2["PE to Storage"] App1["Prod App"] end subgraph Dev["Lower-Assurance Dev Zone"] PE3["PE to Key Vault"] App2["Dev App"] end subgraph Analytics["Separately Administered Analytics Zone"] PE4["PE to Storage"] PE5["PE to Key Vault"] App3["Data Job"] end KV --> PE1 KV --> PE3 KV --> PE5 SA --> PE2 SA --> PE4 App1 --> PE1 App1 --> PE2 App2 --> PE3 App3 --> PE4 App3 --> PE5

Nothing here is automatically insecure.

That is exactly why sprawl survives.

The issue is not endpoint count in isolation. The issue is that shared services are now privately reachable from multiple trust zones with different operational controls, different DNS views, and potentially different security assumptions. If one of those zones is compromised, the attacker may inherit private line of sight to services that were mentally modelled as more tightly contained.

Real-World Impact

This is the point where the article has to matter beyond architecture diagrams.

Design impact

A second Private Endpoint to the same service is not automatically a problem.

A second Private Endpoint in a different trust zone should be treated as architectural debt by default until someone can justify why compromise of that zone should still permit private reachability to the target service.

That is the design decision most teams skip.

They ask whether the application needs private access. They do not ask whether this particular network should be allowed to host a private access path to that service. Those are different questions. The second one is the security question.

If the hosting network is lower-assurance, loosely governed, or simply administered by a different team with different standards, then the new endpoint is not just enabling connectivity. It is extending the service’s effective internal exposure.

Deployment impact

Private Endpoint sprawl is often created by valid infrastructure-as-code.

That is why it is easy to miss.

Every endpoint can be deployed through a clean module, approved through a normal workflow, and attached to the right subnet. Nothing looks broken in the deployment pipeline. The problem is that deployment success says very little about whether the overall estate should contain that many private access paths to the same service.

In other words, good IaC can still encode a bad reachability model.

Operational impact

In an incident, the question is no longer:

Does this service have private access?

It becomes:

How many private origins can still reach it, and which of those no longer belong to a workload anyone actively operates?

That is a much harder question to answer under pressure.

The moment suspicious access appears against a vault, storage account, or database, responders need to understand:

Which Private Endpoints connect to it
Which subscriptions and resource groups own those endpoints
Which virtual networks and subnets host them
Which DNS zones make the target resolvable
Which endpoints still correspond to real workloads
Which paths were approved historically but no longer fit the current design

If you cannot answer those questions quickly, your containment options are slower and your confidence in the service boundary is weaker than you thought.

Security impact

The security issue is not that Private Endpoints bypass service authentication. They do not.

The issue is that they increase the set of internal origins from which authenticated access can be attempted after compromise, reduce confidence in where the service is actually reachable from, and make it harder to distinguish intended private access from inherited shadow paths.

That matters in practice.

An attacker with a foothold in a lower-assurance or forgotten network does not need the endpoint itself to be misconfigured. If that network still has private resolution and routable reachability to a high-value service, the attacker has inherited a path that may not exist in anyone’s current threat model. Even if identity controls still block them initially, the blast radius, staging options, and containment assumptions have changed.

That is why sprawl is an attack-surface problem rather than just an inventory problem.

Architectural Symptoms of Sprawl

Sprawl is usually visible through patterns, not labels.

The same service has Private Endpoints in multiple differently trusted networks

That should trigger scrutiny immediately.

Not because multiple endpoints are always wrong, but because duplicated private access across trust zones should be presumed to be debt until proven otherwise. If the justification does not survive compromise-based reasoning, it is not a strong justification.

Service owners cannot enumerate all private access paths confidently

If the team responsible for a sensitive shared service cannot quickly identify all approved Private Endpoint connections and where they land, then part of the service boundary already lives outside that team’s usable control.

That is not a documentation issue. It is an exposure issue.

DNS behaviour varies by environment in ways no one can explain cleanly

When a service resolves privately in some places, publicly in others, and through different linked DNS constructs across the estate, teams tend to treat it as naming complexity.

Often it is evidence that connectivity spread faster than architecture discipline.

Retired workloads still leave active private access behind

This is one of the clearest forms of shadow access.

The application may be gone, but the endpoint remains, the connection is still approved, and the target service is still privately reachable from that network. That path may not be monitored closely because everyone thinks the workload was retired.

Environment separation exists on paper more than in reachability

The problem is not that dev, test, analytics, and prod are different labels.

The problem starts when differently administered or lower-assurance networks can host equivalent private access paths into shared services that people assume sit behind production-grade controls. At that point, your environment model is doing more work than the network design.

Implementation Example: Inspecting for Duplicated Private Reachability

For this topic, the useful artefact is not deployment code. It is an inspection pattern.

A simple Private Endpoint inventory is rarely enough. What matters is whether the same target resource is reachable through several endpoints spread across different subscriptions or ownership boundaries. That is the shape of sprawl.

Azure CLI example

The following command is intentionally basic, but it is more useful than deployment syntax for this discussion because it starts with the right question: which target resources have multiple Private Endpoints pointing at them?

1
2
3
4
5
6
7
8
9


az network private-endpoint list \
 --query "sort_by([].{
 pe:name,
 rg:resourceGroup,
 subscription:id,
 subnet:properties.subnet.id,
 targets:properties.privateLinkServiceConnections[].properties.privateLinkServiceId
 }, &pe)" \
 -o json

On its own, this is just raw inventory. The useful next step is analytical, not procedural:

Group by target resource ID
Look for shared services with multiple endpoints
Check whether those endpoints sit in different subscriptions or trust zones
Identify endpoints whose owning workload is retired, unclear, or differently administered

The interesting cases are not simply “many Private Endpoints exist”. The interesting cases are “this one high-value service is privately reachable from more places than the architecture claims”.

What to look for

A small synthetic example makes the point:

Target service	Private Endpoint count	Subscription spread	Trust zone spread	Owner clarity
Shared Key Vault A	3	3	Prod, Dev, Analytics	Partial
Storage Account B	2	1	Prod only	Clear
SQL Server C	1	1	Prod only	Clear

Only one of these rows should make you uncomfortable immediately.

Not because three is a magic number, but because a shared secret store privately exposed across multiple administrative or trust boundaries is exactly where “private” starts to mean “unseen”.

Gotchas and Edge Cases

Some multi-endpoint designs are valid

Yes, there are legitimate reasons to expose the same service privately into multiple networks.

But legitimacy should be demonstrated, not assumed. If those endpoints cross trust boundaries, the burden of proof should be higher. “The application needed to connect” is not enough on its own.

Counting endpoints alone is a weak metric

A large estate may have many Private Endpoints without having serious sprawl.

The stronger signal is duplicated reachability to the same sensitive service across different trust zones, ownership boundaries, or stale workload footprints.

Endpoint inventory is not the same as effective reachability

Even with a good list of endpoint resources, you can still misunderstand exposure if you ignore DNS links, peering, routing, or path changes introduced by centralised network patterns.

Private access is a system property, not just a resource property.

Approved once does not mean appropriate now

An endpoint may have been justified when created and still be risky now.

Architectures change. Environments get repurposed. Ownership shifts. Old exceptions become inherited assumptions. Historical approval does not preserve present validity.

Best Practices

Within the bounds of this post, the strongest practices are architectural.

Treat every new Private Endpoint as a new internal exposure point

Do not review it as routine plumbing.

Ask which new network origins now gain private line of sight to the service, and whether those origins still fit the intended trust model.

Default to suspicion when duplicate endpoints cross trust zones

This is the opinionated line worth keeping.

If the same service needs multiple Private Endpoints in differently trusted or differently administered networks, treat that as architectural debt by default until the design can justify it under compromise assumptions.

Review target-service spread, not just endpoint counts

A platform can have a high number of endpoints and still be relatively disciplined.

What you need to understand is which high-value services are privately reachable from how many distinct places, under whose control, and whether those paths still map to live business intent.

Include DNS and ownership in the exposure model

Private access is only meaningful if you understand how workloads discover the service and who controls the network objects that make that possible.

If service ownership does not include usable visibility of private access paths, the service boundary is already weaker than it appears.

Treat orphaned private paths as security-relevant until proven otherwise

A Private Endpoint attached to a retired, forgotten, or poorly understood workload should not be considered harmless background noise. It should be treated as shadow access until someone proves it still belongs in the architecture.

🍺

Brewed Insight:

Private Endpoint sprawl is what happens when private connectivity stops being a deliberate design and becomes a habit.

The danger is not that private access makes a service insecure by itself. The danger is that duplicated private paths quietly reshape trust, reachability, and incident assumptions until your architecture says “contained” while your network says otherwise.

Learn More

Private Link Doesn’t Stop Exfiltration. It Just Changes the Route

Tue, 16 Jun 2026 00:00:00 +1000

You can disable public network access, tighten internet egress, and still leave a perfectly usable path for data to leave the workload.

That is the trap with Private Link. It reduces one kind of exposure while making another kind of path feel safe by default. Once a service is reachable over a Private Endpoint, it starts behaving like trusted internal plumbing. In a lot of estates, that trust arrives long before anybody has defined whether the path should exist, who should own it, or how broadly it should resolve.

That is why this post treats Private Endpoints as part of the internal attack surface, not as a security boundary.

The practical question is not whether the traffic stays private.

It is whether the trust relationship created by that private path is explicit, constrained, and observable enough to rely on.

The Mental Model

The common assumption is familiar:

“If the service has no public endpoint and is only reachable over Private Endpoint, then exfiltration risk is largely removed.”

That sounds neat on a slide. It breaks in real estates.

Private Endpoint does not mean data cannot leave. It means data can leave through a path that now looks internal, often carries less scrutiny, and is easier to describe as “approved” without proving what that approval actually covers.

The more useful mental model is this:

A Private Endpoint is a trust edge.

It is not just a private IP for a platform service. It is a decision to make a managed service reachable from a specific network context under a specific name-resolution model, with all the downstream service behaviour and authorisation complexity that implies.

That should change how you design, deploy, and operate. You should review a new Private Endpoint the way you would review any new trust relationship, not the way you would review a harmless network attachment.

How It Really Works

Private Link gives your workload a private network path to a supported Azure platform service. DNS resolution typically steers the client to the Private Endpoint IP, and the Azure fabric carries the traffic to the target service.

That changes the shape of the path, but not the need to govern it.

A Private Endpoint by itself does not grant meaningful data access. The service behind it still enforces its own authentication and authorisation model. That matters, because the real exfiltration risk appears when three things combine:

private reachability
broad or inherited name resolution
service permissions that allow data use, storage, or onward movement

That combination is where an unexamined data path emerges.

So the real issue is not “Private Link secretly bypasses all security”. It does not.

The issue is that many teams govern the endpoint object, but not the trust relationship around it:

which workloads can resolve the name
which subnets can reach the interface
which identities can use the service meaningfully
which service instance sits behind the endpoint
which downstream service behaviours are now in scope

That is the operational gap. The platform gives you private transport. It does not tell you whether the resulting path should be trusted.

A lot of Azure estates now have strong language around “no public access” and “private-only service consumption”. Both can be sensible controls. But they often create an unhelpful shortcut in architecture reviews:

public endpoint disabled
Private Endpoint deployed
issue considered solved

It is not solved. It has moved.

If a workload can privately reach a storage account, database, or messaging service and has the service-level permissions to use it, then you already have a sanctioned outbound data path. The fact that the packet did not hit the public internet does not make that path harmless.

This is where the trust-edge model matters. A Private Endpoint should not be assessed as “more secure networking” in the abstract. It should be assessed as a concrete relationship between:

a source workload
a resolution path
a destination service
a set of service permissions
a trust boundary

If one of those is undefined, the path is probably being trusted implicitly.

DNS Is Where Trust Quietly Expands

In many Azure estates, the most important policy decision behind a Private Endpoint is not the endpoint itself.

It is which networks are allowed to resolve the name.

This is one of the easiest places for accidental trust expansion to happen. A Private Endpoint may be created for one application or subnet, but the corresponding private DNS zone is often linked far more broadly than the original use case required. Once that happens, reachability stops being a narrow application decision and starts becoming a platform-wide convenience feature.

That changes something important operationally.

A service that was supposed to be privately reachable by one workload can become resolvable by many workloads. If network paths and service permissions also line up, you have quietly widened the set of systems that can use that service as a data path.

That is not a DNS hygiene problem. It is an architecture problem with DNS symptoms.

A Typical Exfiltration Pattern Without the Hype

We do not need to get into malware behaviour or offensive detail to see the design issue.

A common pattern looks like this:

an application subnet can resolve a private service name
the subnet can reach the Private Endpoint
the workload has valid service credentials or managed identity access
the destination service is treated as inherently safe because it has no public endpoint
the path is not reviewed as an outbound trust relationship

At that point, the environment has not eliminated outbound data movement. It has created a low-friction private route for it.

The most common examples are not exotic:

Private storage as an internal sink

A private-only storage account can become an internal drop location simply because it is reachable, resolvable, and writable from more places than intended.

East-adjacent movement across landing zones

A workload in one application trust zone may be able to write data to a private service hosted in another platform, subscription, or spoke. The traffic stays private, but the trust boundary crossing is real.

Service-mediated onward movement

The first hop may be private, but once data lands in the service, downstream platform behaviours matter. Export, replication, integration, or secondary consumers may extend the effective data path well beyond the source workload’s original boundary.

The mistake is not using these services. The mistake is reviewing only the transport path and ignoring what the service is now allowed to do in the broader design.

Visualising the Problem

flowchart LR A[Source workload] --> B[Private DNS resolution] B --> C[Private Endpoint] C --> D[Azure PaaS service] D --> E[Data written or staged] D --> F[Service-side downstream behaviour] D --> G[Consumer in another trust zone] H[Shared DNS zone links] --> B I[Service permissions] --> D style C fill:#d9edf7,stroke:#31708f style D fill:#fcf8e3,stroke:#8a6d3b style E fill:#f2dede,stroke:#a94442 style F fill:#f2dede,stroke:#a94442 style G fill:#f2dede,stroke:#a94442 style H fill:#f5f5f5,stroke:#666666 style I fill:#f5f5f5,stroke:#666666

The useful takeaway here is that the Private Endpoint is not the whole story. The meaningful risk sits in the combination of resolution scope, network reachability, service authorisation, and downstream service behaviour.

Disabling public access is often the right move. It removes a class of exposure cleanly.

But there is a difference between reducing exposure and controlling data paths.

“No public endpoint” can create false confidence because it sounds like a complete answer. In practice, it often just shifts scrutiny away from the remaining path. The service is now considered private, the traffic looks internal, and the path gets less attention precisely because it appears more controlled.

That is how unmanaged trust grows in mature environments:

the path is real
the path is approved in principle
the scope of that approval is unclear
visibility is fragmented
ownership is diluted across networking, platform, and application teams

The end state is not a dramatic security failure. It is something more common and more dangerous: a private data path that nobody is actively governing.

How This Changes Design, Deployment, and Operations

This is the practical anchor.

Design

Treat each Private Endpoint as a trust-edge decision.

Do not stop at “the app needs private access to Storage”. Define:

which workload needs it
which exact service instance it should reach
which networks should resolve the name
which trust boundaries are being crossed
which downstream service behaviours are acceptable
which cases are explicitly out of scope

That changes design because you stop modelling Private Endpoints as generic network plumbing and start modelling them as approved service relationships.

Deployment

Treat creation of a Private Endpoint as introduction of a new sanctioned private data path.

That means the deployment is not complete when the resource exists. It is complete when the trust conditions around it are also understood:

source scope
DNS scope
destination ownership
expected service use
reviewability

If those are missing, the deployment is technically correct but architecturally incomplete.

Operations

Review Private Endpoints the way you would review long-lived firewall rules or peering relationships: as objects that outlast the project that created them.

That changes operations because your questions become sharper:

which workloads can resolve this service name today
which trust zones can reach this endpoint now
does the destination still have a valid owner
would anybody notice if a workload started using this path differently
does the current DNS linkage still match the original design intent

That is far more useful than simply counting how many Private Endpoints exist.

Governance Query Example

For this kind of article, deployment syntax is not the interesting artefact. The harder problem is whether the estate can identify Private Endpoints that have become unmanaged trust relationships.

A governance-oriented query is more useful than a create example because it tests whether your environment can answer basic architectural questions at scale.

The Azure Resource Graph query below looks for Private Endpoints and surfaces signals that deserve review:

missing ownership tags
missing business-purpose tags
the subnet hosting the endpoint
the target resource behind the connection

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


resources
| where type =~ 'microsoft.network/privateendpoints'
| extend peSubnetId = tostring(properties.subnet.id)
| extend connections = properties.privateLinkServiceConnections
| mv-expand conn = connections
| extend targetResourceId = tostring(conn.properties.privateLinkServiceId)
| project
 subscriptionId,
 resourceGroup,
 privateEndpoint = name,
 location,
 peSubnetId,
 targetResourceId,
 owner = tostring(tags.Owner),
 businessPurpose = tostring(tags.BusinessPurpose)
| extend ownerState = iif(isempty(owner), 'Missing', 'Present')
| extend purposeState = iif(isempty(businessPurpose), 'Missing', 'Present')
| order by ownerState desc, purposeState desc, subscriptionId asc

This does not prove exfiltration risk by itself, and it should not be oversold. What it does show is whether your estate can identify private service paths that lack even basic ownership and intent metadata.

That matters because unmanaged trust tends to appear before confirmed misuse does.

If your platform team cannot quickly answer who owns a Private Endpoint, why it exists, and which service it reaches, then your “private-only” posture is probably carrying more implicit trust than you think.

Indicators That the Data Path Is Being Trusted Implicitly

These are the signs I would look for in a real environment.

Private DNS zone links are broader than the application need

This is one of the strongest indicators that convenience has overtaken design intent.

Private Endpoints exist without clear ownership metadata

If the object is live but nobody clearly owns the path, it is already under-governed.

Shared services are reachable across multiple trust zones by default

That may be intentional, but it should be visible and explicitly defended, not inherited silently.

Architecture documents describe “private access” but not “approved data destinations”

That wording usually means the transport decision was reviewed but the data-path decision was not.

Public access is disabled and that is treated as the end of the conversation

This is the most common mental shortcut. It reduces one risk and masks another.

Gotchas & Edge Cases

Private reachability is not the same as authorised use

A workload still needs valid service-level permissions. The risk comes from the combination of path and permission, not from private transport alone.

DNS scope can widen faster than endpoint deployment

You can accidentally expand reachability through name resolution changes without creating any new Private Endpoint resources.

Cross-subscription does not mean cross-trust is understood

Administrative boundaries are not the same as trust boundaries. A private path into another team’s service is still a trust decision even if it lives inside the same tenant.

Service subresources matter

Different subresources can expose materially different capabilities. Reviewing access only at the service label level is often too coarse.

Best Practices

1. Review Private Endpoints as trust edges

Make this the default posture. If a new endpoint creates a new path to a managed service, it deserves trust-boundary review.

2. Keep DNS scope as narrow as the use case

Private resolution should be deliberate. Broad inherited zone links are one of the easiest ways to create accidental trust expansion.

3. Separate transport approval from data-path approval

A service being reachable privately does not automatically make it an approved destination for sensitive or high-value data.

4. Require ownership and business purpose for every Private Endpoint

If the relationship matters, it should be attributable. If it is not attributable, it should not be trusted by default.

5. Review by trust boundary, not just by subscription or VNet

The real question is who can now reach which service under which name and permissions, not which administrative container the resource lives in.

6. Assume private PaaS traffic is under-observed until proven otherwise

Do not assume your visibility model kept up with your connectivity model.

🍺

Brewed Insight: Private Link is very good at removing public exposure. That is exactly why it can hide bad assumptions so well. If the service is private, broadly resolvable, and meaningfully usable, then you do not have “no exfiltration path”. You have a trusted one.

Learn More

Private Endpoint Doesn’t Save You from DNS

Thu, 11 Jun 2026 00:00:00 +1000

When teams talk about securing Azure PaaS with Private Endpoint, the conversation usually settles on the network path.

The service now has a private IP. Traffic stays off the internet. Exposure is reduced. Everyone breathes a bit easier.

That is not wrong. It is just incomplete.

A Private Endpoint changes how traffic reaches a service, but it does not, by itself, guarantee that the client is reaching the right service. In most real deployments, that decision still rides on DNS. The path may be private, but the destination is still selected by name resolution.

That changes something you design, deploy, and operate straight away: a Private Endpoint gives you a private transport path, not destination integrity.

The Mental Model

The common assumption is simple:

“We replaced the public endpoint with a private one, so the connectivity risk is mostly solved.”

That assumption holds only if you treat connectivity as a pure routing problem. Most workloads do not connect to abstract network paths. They connect to service names. If the wrong system answers the naming question, the network can still do exactly what it was configured to do while the application reaches the wrong destination, fails unexpectedly, or inherits trust from systems its owners never intended to rely on.

Treating Private Endpoint as the security boundary while treating DNS as background plumbing is a category error.

A private IP narrows exposure. It does not remove the need to trust the path that tells clients where that IP should be.

How It Really Works

Private Endpoint consumption feels clean because the application often keeps using a familiar service name. DNS simply returns a private address instead of a public one, and the application connects as normal.

That convenience hides an important dependency chain:

The client must query the intended resolver.
That resolver must use the intended zones and records.
The returned answer must identify the intended Private Endpoint.
No intermediate control should override that answer unexpectedly.
The service-layer connection must still validate against the expected service identity.

The critical point is that Private Endpoint secures reachability to a private destination. DNS still participates in deciding which destination that is.

That distinction matters because different DNS failures lead to different outcomes:

some failures break access entirely
some send clients to an unexpected private target
some change which administrative domain effectively controls service targeting
some create confusing partial outages that look like network or platform faults

Not all of those outcomes are compromise. That is exactly why this gets missed. Engineers often reserve the word “security” for direct unauthorised access, when in practice loss of destination control is already a security-relevant condition.

A Simple Trust Map

flowchart LR A[Application workload] --> B[Configured DNS resolver] B --> C[Private DNS authority or delegated resolution path] C --> D[Private Endpoint IP] D --> E[Azure service via Private Link] X[DNS admin influence] Y[Resolver path drift] Z[Incorrect or stale record] X -. changes authority .-> C Y -. changes dependency .-> B Z -. changes target selection .-> D

This is the part many designs flatten into “internal DNS”.

From a threat-model perspective, that is too coarse. The question is not just whether the answer is private. The question is who can influence the answer, and therefore influence where trusted traffic goes.

Where the Attack Surface Actually Appears

Private DNS becomes part of the trust boundary

Once a workload depends on private DNS records to reach a Private Endpoint-backed service, those records stop being neutral support objects. They become part of the application’s effective trust boundary.

That is the shift many teams miss.

A private DNS zone, a linked resolution path, or an override record may look operationally harmless because none of them move packets by themselves. But they can still influence service targeting. In a Private Endpoint architecture, that means they can influence which private destination a workload treats as authoritative.

That does not mean every DNS issue enables interception or data theft. Often it does not. But it absolutely can:

deny access to a required service
redirect clients towards an unintended private destination
shift effective control of service targeting into another administrative domain
create persistent failure modes that survive application redeployments and network reviews

That is enough to treat DNS as attack surface rather than plumbing.

Shared DNS paths broaden trust beyond the VNet

This is where the comforting subnet diagram starts to mislead.

A workload may sit in an isolated landing zone, use a locked-down subnet, and connect only to Private Endpoints. On paper, that looks tightly contained. But if name resolution depends on shared DNS services, central platform teams, hybrid resolvers, or external administrative paths, then the workload’s connectivity trust extends beyond its own network boundary.

In other words, the VNet does not fully describe who influences where that workload goes.

That matters in larger Azure estates because teams often assume Private Endpoint localises risk to the consuming network. In practice, DNS can reintroduce shared dependencies in ways the network design no longer makes obvious.

DNS risk is persistent, not a day-0 problem

Private Endpoint risk is often discussed as a provisioning concern: the endpoint is created, the record exists, the application connects, done.

That is the wrong lifecycle.

DNS is mutable by design. Records change. Zones move. Links are added. Resolver paths are centralised, migrated, inherited, or quietly overridden. Organisationally, ownership drifts even when infrastructure diagrams do not.

That means the DNS risk attached to a Private Endpoint is not limited to initial deployment quality. It persists as long as the workload depends on that resolution path. An attacker, careless change, or platform-side drift does not need to touch the application subnet or the Private Endpoint NIC to change runtime behaviour.

Real-World Impact

Design review needs a different question

During design review, the question is no longer just:

“Does this workload use a Private Endpoint?”

It also needs to be:

“Who can change where this workload believes that service lives?”

That is a materially different architecture question.

It forces you to examine DNS ownership, zone authority, resolver dependencies, and shared platform controls as part of application connectivity trust. If those controls sit outside the workload’s intended trust boundary, then part of the workload’s security posture sits outside that boundary too.

Shared services can quietly centralise influence

Centralised DNS often looks like operational maturity. Sometimes it is. But it also centralises the ability to change service targeting for many workloads at once.

That does not automatically make centralisation wrong. It does mean the blast radius is architectural, not just administrative.

If a central DNS path influences resolution for Private Endpoint-backed services across multiple landing zones, then one change path may affect systems that otherwise look isolated in network diagrams. For technical decision makers, that should change how DNS authority is classified. For operators, it should change which dependencies get examined first when failures appear inconsistent.

Incident response assumptions need tightening

In incident triage, “it resolved to a private IP” should not be treated as proof that the workload reached the intended service.

That assumption is too weak for Private Endpoint architectures.

A private answer may still be stale, unintended, inherited from the wrong resolution path, or aligned to the wrong environment. If teams use “private IP observed” as a proxy for “trustworthy destination confirmed”, they will misdiagnose issues and overlook one of the most important control dependencies in the path.

This is where the article’s thesis stops being theoretical. It changes how you investigate outages, dependency failures, and unexplained behaviour in supposedly isolated environments.

A Behavioural Example

Consider an application that retrieves secrets from Azure Key Vault through a Private Endpoint.

The application team has done the expected things. Public network access is restricted. The consuming subnet can reach the Private Endpoint. Egress is tightly controlled. On a network diagram, the design looks sound.

But the vault name resolves through a shared DNS path outside the application team’s direct control.

A later change in that path does not need to alter routes, firewall rules, or the Private Endpoint itself to affect the application. It only needs to alter where the application believes the vault lives. The likely outcome is not dramatic movie-style interception. More often it is failed access, wrong-environment targeting, or a dependency outage that presents like an Azure networking issue even though the transport path is doing exactly what it was told.

That is the operational trap: the application team can lose effective control of service targeting without any visible network change in its own subscription.

Gotchas & Edge Cases

“Private” is not the same as “correct”

A private IP answer only tells you something about address scope. It does not prove the answer came from the intended authority or points to the intended service instance.

DNS influence is easy to hide inside legitimate administration

A malicious route change often looks suspicious. A DNS record change may look like normal infrastructure maintenance, especially in shared services environments.

Network isolation can disguise naming dependency

The more locked down the packet path becomes, the easier it is for teams to assume the remaining dependencies are benign. In Private Endpoint architectures, that assumption gets dangerous quickly.

Service-layer controls still matter

DNS influence does not automatically equal successful compromise. Authentication, authorisation, and certificate validation still shape the final outcome. But they do not make DNS irrelevant; they define how far a bad DNS outcome can propagate.

Best Practices

Treat DNS authority as part of connectivity security

If DNS determines which private destination a workload reaches, then DNS authority is not ancillary. It is part of the workload’s effective connectivity security model.

Review change authority, not just network reachability

Packet path reviews are not enough. You also need to understand who can change resolver behaviour, zone data, or other name-resolution dependencies that alter target selection.

Classify shared DNS services by blast radius

A shared resolver or private DNS authority serving multiple Private Endpoint consumers is a multi-system trust dependency. Treat it accordingly.

Separate private transport from trusted destination in your thinking

A packet can stay on a private path and still fail to reach the intended service. Those are different properties, and mature designs treat them separately.

🍺

Brewed Insight: Private Endpoint reduces exposure, but DNS still decides where trust lands. If you model Private Endpoint as the boundary and DNS as plumbing, you are securing the road while outsourcing the destination.

Learn More

Private Endpoint Control Planes: Private Reachability Isn’t Trusted Reachability

Tue, 09 Jun 2026 00:00:00 +1000

You can take a sensitive service off the public internet, pin it behind a Private Endpoint, and come away feeling like the trust problem is mostly solved.

That feeling is exactly where the trouble starts.

Private Endpoints can reduce exposure. They can narrow the network paths that reach a service. But they do not prove that the environments consuming that service privately are legitimate, or that the administrative chain which created that private path deserves trust.

The real design error is not exposing a service privately. It is assuming that any environment able to consume it privately has therefore earned trust.

That is a control-plane problem, not a networking success story.

The Mental Model

The common assumption is simple:

If a service is only reachable through a Private Endpoint, then access is effectively trusted because it is no longer public.

That assumption compresses two different questions into one:

how traffic reaches the service;
whether the thing reaching it should be trusted.

Private Endpoints only answer the first one.

They change the path. They do not validate the consumer, the administrators who created the path, or the approval decisions that allowed it to exist. The private IP is not the trust boundary. It is the output of a series of management decisions.

So the useful shift in mental model is this:

private connectivity is a routing property
trusted connectivity is an authority decision
Private Endpoints affect the first one, not the second

The moment a team treats private reachability as evidence that a consumer environment has been legitimately trusted, they stop inspecting the layer where trust was actually granted.

How It Really Works

Private Endpoint is usually discussed as if it were a networking feature with some management overhead attached.

That framing is backwards.

It is a control-plane object that creates a private data-plane path.

That path exists only because a chain of administrative decisions makes it exist:

a Private Endpoint resource is created;
it is placed in a subnet within a virtual network;
it references a specific Private Link-capable subresource;
a connection request is raised and allowed through the target service’s approval model;
DNS then enables clients to use that private path.

By the time packets flow, the trust decisions have already happened.

Approval is a trust decision

Approval is often treated as a minor workflow event. It is not. It is the point at which a service owner, delegated operator, or service-specific approval path allows a particular consumer environment to establish private reachability.

That is a trust decision.

It is also one of the reasons Private Endpoint can be over-trusted architecturally. The assurance conveyed by a successful private connection is not perfectly uniform across Azure services or ownership models. Teams generalise from one service pattern to another, see a working private path, and assume it carries the same trust meaning everywhere. It does not.

If your architecture treats “connected privately” as if it implied a consistent trust posture across services, you are relying on a certainty the platform does not actually provide.

A Private Endpoint is a separate Azure resource. It can live in a different resource group, subscription, or operating domain from the service it connects to.

That is not just an implementation detail. It means the protected service and the private path to it can have different lifecycle owners, different administrative scopes, and different review habits.

This is the point many reviews miss: hardening the service does not tell you enough if someone else can still instantiate and retain private reachability to it.

Administrative separation is not trusted separation

Subscriptions and resource groups are useful operational boundaries. They are not evidence of trustworthy separation by themselves.

If the same administrators, inherited permissions, or approval practices can still bridge those scopes through management actions, then the boundary is structural, not trustworthy.

This is the design mistake that shows up repeatedly in Azure estates: teams see separate subscriptions and infer separate trust. In reality, they have reviewed layout, not authority.

Trust Flow, Not Just Packet Flow

The control-plane risk is easier to see when the trust relationships are explicit.

flowchart LR A[Identity with Private Endpoint management access] --> B[Create or modify Private Endpoint] B --> C[Consumer VNet and subnet placement] B --> D[Connection request to target resource] D --> E[Service-specific approval path] E --> F[Private connectivity established] F --> G[Private DNS mapping] G --> H[Client workload uses private path] I[Platform admin] --> C J[DNS admin] --> G

The interesting part is not where the packets flow. It is where trust gets asserted:

the identity allowed to create the endpoint;
the team controlling the subnet where it lands;
the approval path for the target resource;
the DNS authority that makes the path usable.

If those actors sit in different places, with different review standards, then “internal-only access” is really the product of several loosely connected trust decisions.

Real-World Impact

This changes how you should interpret private connectivity in production.

Private access does not prove the consumer was ever properly vouched for

A service may be reachable only over Private Endpoint and still be exposed to environments that were never meaningfully validated as legitimate consumers.

That is the central operational mistake: teams use private reachability as a proxy for consumer legitimacy.

The path is private. The trust judgement behind it may be weak, inherited, stale, or simply assumed.

Service owners can lose control of access without changing the service

If endpoint creation, subnet placement, approval, and DNS are controlled by different operating groups, then access can expand without the target service configuration changing in any obvious way.

That means a service can look hardened while the practical conditions of who can reach it are being altered elsewhere.

Drift preserves trust long after intent disappears

A stale Private Endpoint is not just a clean-up problem. It can preserve private access from an environment that has been retired, repurposed, handed to another team, or no longer deserves the implied trust of a live private path.

Most control-plane risk does not arrive dramatically. It lingers.

How would this change something I design, deploy, or operate?

It should change your review posture.

Do not stop at “is this service private?” Ask which identities, teams, and approval paths can create or preserve private reachability to it. If the answer depends on administrative sprawl, inherited control, or assumptions about what “internal” means, then the architecture is trusting more than it intends.

Abuse Scenarios That Matter

The risk is not endpoint creation in isolation. The risk appears when endpoint creation, placement into a reachable network, service approval, and usable name resolution combine into a private path that looks legitimate simply because it works.

A consumer environment gains a private path it was never meant to have

An operator creates a Private Endpoint into a subnet already reachable by workloads they control. The target service connection is then approved through a weak or overly routine process, and the necessary DNS conditions are in place for those workloads to resolve the service privately.

Nothing has become public. But a new trusted-looking path now exists from an environment nobody properly vouched for.

Approval becomes habit instead of judgement

A team responsible for approving Private Endpoint connections sees requests from “internal” subscriptions and treats them as normal by default. The endpoint is private, the naming looks familiar, and the approval goes through without a real question being asked about whether that consumer environment should have reachability at all.

That is not a tooling problem. It is trust being inferred from private placement.

Old environments retain private access by inertia

An application is migrated or retired, but the Private Endpoint remains, DNS still resolves, and the consumer network is still reachable. The original service owner assumes the old path was cleaned up. The platform team assumes the service owner still needs it.

No one is actively deciding to trust the path. The trust simply never got revoked.

Implementation Example

This is not a deployment guide, but the resource shape is useful because it exposes where the control-plane split actually lives.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


resource pe 'Microsoft.Network/privateEndpoints@2023-09-01' = {
 name: 'pe-app-sql-prod'
 location: resourceGroup().location
 properties: {
 subnet: {
 id: '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-network-prod/providers/Microsoft.Network/virtualNetworks/vnet-hub-prod/subnets/snet-private-endpoints'
 }
 privateLinkServiceConnections: [
 {
 name: 'sqlConnection'
 properties: {
 privateLinkServiceId: '/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-data-prod/providers/Microsoft.Sql/servers/sql-prod-01'
 groupIds: [
 'sqlServer'
 ]
 requestMessage: 'Prod application connectivity'
 }
 }
 ]
 }
}

The useful part is not the syntax. It is what the object tells you:

the endpoint lives in its own management scope;
the subnet is controlled separately;
the target service may sit under different ownership;
the connection request is a trust event before it is a traffic path.

That is why “the service is private” is not enough. The service may be private while the authority to create private reachability sits in a different part of the estate entirely.

You can also inspect Private Endpoint connection state directly:

1
2
3


az network private-endpoint-connection list \
 --id "/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-data-prod/providers/Microsoft.Sql/servers/sql-prod-01" \
 --query "[].{name:name,status:properties.privateLinkServiceConnectionState.status,description:properties.privateLinkServiceConnectionState.description}"

The command matters less than the discipline behind it. If you are not looking at which consumers have private connectivity to a service, you are trusting historical approvals more than current intent.

Gotchas & Edge Cases

Working connectivity can disguise poor trust decisions

Once a name resolves privately and the application works, the path starts to feel legitimate by default. But functional connectivity is not proof that the consumer environment was ever supposed to be trusted.

Inconsistent service behaviour creates false assumptions

Private Endpoint approval and ownership patterns vary across Azure services. The risk is not just operational complexity. It is that teams assume a consistent trust model where none exists.

Persistence is often the bigger problem than deletion

Accidental deletion creates incidents, so it gets attention. Quietly persistent connectivity is often more dangerous because it preserves trust without forcing anyone to rejustify it.

Best Practices

This is not a role design or privileged workflow post, so I will stay out of RBAC mechanics. The practical design implications are still clear.

Treat Private Endpoint creation as a security-relevant action

Creating a Private Endpoint can extend private reachability to a sensitive service without changing the service configuration itself. That alone makes it worth treating as more than routine network plumbing.

Review private consumers, not just protected services

A service review is incomplete if it asks only how the service is protected and never asks who can privately attach to it.

Treat subscription boundaries as operational structure, not proof of trust

If the same management actors can still bridge those boundaries, then the separation may be useful administratively while meaningless from a trust perspective.

Make one question unavoidable in design review

For any sensitive service exposed through Private Endpoint, ask:

Which identities, teams, and approval paths can create, approve, or preserve private reachability to this service, and why should that imply trust in the consuming environment?

If that question is difficult to answer, the trust model is weaker than the network diagram suggests.

Design lifecycle ownership into the path itself

Private connectivity should have a clear owner, reason for existence, and review trigger. Otherwise, it becomes part of the environment’s inherited internal attack surface.

🍺

Brewed Insight: Private Endpoints are good at making traffic private. They are useless as proof that the private consumer has earned trust. Once private reachability gets mistaken for trusted reachability, the control plane becomes the part of the attack surface nobody is watching.

Learn More

Why “Private” Does Not Mean “Secure”

Thu, 04 Jun 2026 00:00:00 +1000

Private Endpoint has a branding problem.

The word private lands in architecture discussions like a shortcut for safe. Public access is removed, the service gets a private IP, and somewhere between design review and production rollout, reduced exposure gets mistaken for established trust.

That is the mistake.

A private endpoint is useful. Often very useful. But if your security posture improves mainly because you made something harder to reach from the internet, you have changed exposure, not proven safety. You have narrowed the path, not validated the caller, the dependency chain, or the operational control around it.

Private Endpoint reduces exposure; it does not create trust.

That is the lens for this post.

The Mental Model

The failure usually starts with a quiet assumption:

If a resource is reachable only over private connectivity, it is now a trusted internal service.

That assumption sounds reasonable because private addressing still carries a lot of inherited meaning. It feels contained. Managed. Ours.

In Azure, that is a dangerous shortcut.

Private Endpoint changes where traffic can come from. It does not answer whether the source is legitimate, whether the network path is well governed, whether DNS is correct, or whether the service is being reached by something already compromised.

The deeper problem is not technical misunderstanding. It is classification.

When teams treat Private Endpoint as a security control in its own right, they start making downstream design decisions as though network privateness is evidence of trust. That is where architecture drifts:

internal paths become loosely trusted
segmentation becomes harder to justify
DNS gets treated as plumbing instead of a security dependency
control-plane permissions become more powerful than the design admits
monitoring gets weaker because “private” has already been mentally filed under “safe”

That is why this is more than semantics. Misclassifying the control changes the system built around it.

How It Really Works

Private Endpoint gives an Azure service a private IP in your virtual network through Azure Private Link. That changes the reachability path to the service.

It does not make the service inherently trustworthy. It does not validate the caller. It does not harden the data path on its own. It does not replace authentication, authorisation, encryption, governance, or operational verification.

What it does do is narrow the set of places from which the service can be reached.

That matters. Exposure reduction is real. Internet-wide scanning, casual probing, and broad unsolicited connectivity become less relevant when access is forced through private network paths. That is a legitimate security improvement.

But it is still only one kind of improvement.

The mistake is turning this:

Fewer things can reach the service

into this:

Things that can reach the service are now trustworthy

Those are completely different claims.

A more accurate model is:

Private Endpoint is an exposure-reduction mechanism
It is not a trust mechanism
It is not a security boundary
It should not be treated as a compensating control for weak architecture elsewhere

That last point matters most. The architectural mistake is not deploying Private Endpoint. The mistake is using it to justify trust decisions it was never designed to support.

Private Endpoint as Part of the Attack Surface

If you are threat modelling properly, a Private Endpoint should be treated as part of the internal attack surface.

That means the question is not “is this service private now?”

It is closer to:

which networks can route to it?
which systems can resolve its name?
which workloads can reach it after compromise?
which teams or automation can create, approve, or modify the connection path?
which changes to DNS or endpoint lifecycle would silently alter trust assumptions?
which telemetry would tell us the endpoint is being used in a way we did not intend?

That is a very different posture from “public access disabled, job done”.

The dependency chain is the story

flowchart LR A[Workload or User] --> B[DNS Resolution] B --> C[Routing to Private IP] C --> D[Private Endpoint] D --> E[Private Link Mapping] E --> F[Azure Service] G[Peering / Hybrid Connectivity] --> C H[RBAC / Policy / Approval Workflow] --> D I[Private DNS Zone Links / Forwarders] --> B J[Monitoring / Logs / Alerts] --> D style D fill:#d9edf7,stroke:#31708f,stroke-width:2px style B fill:#fcf8e3,stroke:#8a6d3b,stroke-width:1px style H fill:#f2dede,stroke:#a94442,stroke-width:1px style I fill:#f2dede,stroke:#a94442,stroke-width:1px

Private Endpoint is only one component in a chain that includes name resolution, network pathing, control-plane permissions, and ongoing operational ownership.

An attacker does not need to defeat Private Link itself. They need one viable path through the surrounding system.

That is why calling Private Endpoint a security control is too generous. It encourages the wrong mental model about where assurance actually comes from.

Real-World Impact

This changes design and operations in some concrete ways.

1. A compromised internal workload can still use the private path

A storage account or Key Vault behind a Private Endpoint is still reachable by any compromised workload that can route and resolve to it.

If you mentally classified the endpoint as “secure because private”, you are more likely to have under-invested in segmentation, workload isolation, or internal traffic scrutiny. The attacker does not need public ingress. They just need to land somewhere that already sits inside the allowed path.

This is the most common failure of the “private equals safe” assumption: the service is no longer internet-facing, but it is still entirely usable from the wrong place for the wrong reason.

That should change how you design. A Private Endpoint should be treated as a sensitive internal destination, not a trustworthy one.

2. DNS becomes a security dependency, not just a networking detail

Private Endpoint increases your reliance on private DNS zones, forwarding rules, resolver paths, and link governance.

That is not background plumbing. It is part of the trust path.

If DNS ownership is fragmented, forwarding is inconsistent, or zone links are changed without proper control, the architecture can drift without most teams noticing. The service still looks private. The assumptions around how it is resolved and reached may no longer be true.

This should change how you operate. Name resolution for private services needs explicit ownership, change discipline, and verification. If your design depends on DNS but your operating model treats it as somebody else’s problem, you do not have a complete security design.

3. Control-plane permissions can silently reshape trust

The endpoint itself is a data-plane object, but the trust around it is heavily influenced by control-plane actions.

Who can:

create a private endpoint
approve a connection
link or unlink private DNS zones
alter policy exemptions
move workloads into reachable network segments
change routing or forwarding behaviour

Those permissions matter because they can alter who reaches what, and how, without changing the application code or the service itself.

If Private Endpoint is treated as a security control, teams often stop short of asking who can mutate the control surface around it. That creates false assurance. The path is private, but the governance over the path may still be loose.

This should change what you review in design governance. The security question is not just “does this use Private Endpoint?” but “who can change the path, resolution, and approval model around it?”

How would this change something I design, deploy, or operate?

It changes the classification.

I would not treat Private Endpoint as a control that establishes trust. I would treat it as an exposure-reduction mechanism that still sits inside a broader system of trust decisions.

That means:

designing internal reachability as something to constrain, not automatically trust
treating private DNS as part of the security architecture
reviewing control-plane permissions as part of endpoint risk
monitoring private-only service access as potentially high-signal, not low-risk
refusing to let “it’s private” close a design discussion that should still include governance and failure modes

If the design review ends at “public access disabled”, it has ended too early.

Implementation Example: Verify the Dependency Surface, Not Just the Endpoint

The useful operational question is rarely “does a Private Endpoint exist?”

It is more often “what trust and dependency surface now exists because it does?”

A simple example is enumerating endpoint state and DNS relationships so they can be reviewed as part of operational governance rather than assumed to be correct.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# List private endpoints in a subscription with key governance context
az network private-endpoint list \
 --query "[].{
 name:name,
 resourceGroup:resourceGroup,
 location:location,
 subnet:id,
 connections:privateLinkServiceConnections[].privateLinkServiceId,
 nics:networkInterfaces[].id,
 provisioningState:provisioningState
 }" \
 -o table

# List Private DNS zone links for review
az network private-dns link vnet list \
 --resource-group <dns-rg> \
 --zone-name <private-zone-name> \
 -o table

This is not presented as a deployment step. It is a reminder that the operational surface includes more than the endpoint object itself. If you cannot quickly identify which endpoints exist, which networks they live in, and how DNS is linked around them, you are relying on privateness more than you are governing it.

Gotchas & Edge Cases

Private-only can reduce visibility if teams are not deliberate

Some organisations monitor internet-facing services heavily and assume private paths are lower risk. That can create a blind spot where the more sensitive destination gets less scrutiny simply because it is no longer public.

“Internal” often spans more than one trust domain

Peering, hub-and-spoke topologies, hybrid connectivity, and shared platform services can all widen effective reachability. If your architecture talks about “the internal network” as though it were one trust zone, you are already abstracting away the problem.

Exposure reduction can still be the right call

None of this is an argument against Private Endpoint. Reducing public exposure is often sensible and worthwhile. The warning is about over-claiming what that decision buys you.

Best Practices

Treat Private Endpoint as exposure reduction, not trust establishment
Model private DNS as a security dependency with explicit ownership
Review which internal networks and workloads can actually reach private endpoints
Include control-plane permissions and approval paths in the threat model
Monitor access to private-only services as part of your internal attack surface
Challenge any design language that treats “private” as equivalent to “trusted”

🍺

Brewed Insight: Private Endpoint is valuable precisely because it reduces exposure. The trouble starts when that benefit gets inflated into a trust claim. Once “private” becomes shorthand for “safe”, the rest of the architecture starts inheriting confidence it never earned.

Learn More

Designing Networks That Fail Predictably

Tue, 02 Jun 2026 00:00:00 +1000

Every network fails eventually.

Sometimes it’s physical. Sometimes it’s logical. Often it’s self‑inflicted, a containment rule pushed with the best intentions that quietly turns into a kill switch.

The difference between a survivable incident and a chaotic one isn’t whether the network failed. It’s whether the failure behaved the way you expected it to.

Predictable failure isn’t about being pessimistic. It’s about staying in control when parts of the system are no longer trustworthy.

The Mental Model

Common assumption:
“If we design enough resilience and security into the network, failure becomes unlikely and manageable when it happens.”

Why it breaks:
Resilience delays failure; it doesn’t define its shape.

As Azure networks grow, they accumulate invisible dependencies: centralised inspection, forced tunnelling, identity‑driven policy, platform service reachability. Under stress, those dependencies don’t fail cleanly. They fail asymmetrically.

Some flows work. Others silently die. And the controls meant to protect you become the fastest way to lose visibility and access.

Predictable failure starts by accepting that not all controls deserve to survive an incident.

How It Really Works

In real incidents, containment actions usually remove connectivity faster than they restore clarity.

The most common pattern looks like this:

Suspicious activity is detected
Egress is tightly constrained or forced through central inspection
A dependency breaks DNS, identity, logging, update paths
Defender access degrades alongside attacker access
The network is now “secure” but unmanaged

Azure doesn’t distinguish between defensive isolation and self‑denial. The platform will happily enforce whatever policy you give it, even if that policy collapses your ability to respond.

Designing for predictable failure means deciding which capabilities must outlive containment.

Real‑World Impact

This changes how you design, deploy, and operate networks in a very practical way:

You stop treating centralised egress inspection as an invariant
You explicitly prioritise defender access and telemetry over uniform traffic control
You design containment to reduce attacker capability first, not remove all connectivity
You accept that some security controls are conditional, not absolute

The key shift: losing inspection is survivable; losing control is not.

Designing for Controlled Degradation

1. Fail Closed at Trust Boundaries, Not at Egress

Under stress, the first thing you should be willing to lose is cross‑trust communication, not operator reachability.

That means:

East‑west traffic between trust zones fails before north‑south management access
Isolation targets workloads, not the paths used to observe and recover them
Containment reduces blast radius without collapsing the control plane

Centralised egress inspection is valuable, until it becomes the narrowest choke point in the system.

2. Intentionally Relax Centralised Egress Inspection During Containment

This is the uncomfortable trade‑off.

In a containment scenario, it is often safer to temporarily allow direct workload egress than to enforce forced tunnelling through a brittle inspection path.

Why?

Forced egress concentrates failure into a single dependency
When that dependency degrades, logging, updates, and identity often follow
Defender access and telemetry are frequently collateral damage

This is not an argument against inspection. It’s an argument against treating it as non‑negotiable during failure.

Predictable failure means being explicit about this ordering:

I am willing to lose uniform egress inspection before I am willing to lose defender access, telemetry, or recovery paths.

3. Preserve Defender Control Paths at All Costs

If a containment action can sever:

Bastion or jump host access
Break‑glass identities
Log and alert egress
Platform management endpoints

…then it’s not a security control, it’s a denial‑of‑service against your own responders.

Defender paths should be architecturally boring:

Minimal dependencies
Few enforcement layers
Hard to accidentally include in broad deny rules

If these paths disappear during containment, the network has failed chaotically, regardless of how “secure” it looks.

Implementation Example: Encoding Failure Order with NSGs

This example is intentionally simple. It’s not a pattern to copy wholesale, it’s a way to encode failure intent.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


resource workloadNsg 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
 name: 'nsg-workload-zone'
 location: resourceGroup().location
 properties: {
 securityRules: [
 // Allow trusted intra-zone traffic
 {
 name: 'Allow-IntraZone'
 properties: {
 priority: 100
 direction: 'Inbound'
 access: 'Allow'
 protocol: '*'
 sourceAddressPrefix: '10.20.0.0/16'
 destinationAddressPrefix: '*'
 sourcePortRange: '*'
 destinationPortRange: '*'
 }
 }
 // Default deny for cross-zone traffic
 {
 name: 'Deny-CrossZone'
 properties: {
 priority: 4096
 direction: 'Inbound'
 access: 'Deny'
 protocol: '*'
 sourceAddressPrefix: 'VirtualNetwork'
 destinationAddressPrefix: '*'
 sourcePortRange: '*'
 destinationPortRange: '*'
 }
 }
 ]
 }
}

What this demonstrates:

Failure occurs first at trust boundaries
Intra‑zone operation continues
Containment is explicit and reversible
The network degrades along known seams

NSGs alone won’t save you but encoding failure order in policy forces architectural clarity.

Visualising Predictable Failure

flowchart LR subgraph Management Admins Bastion end subgraph ZoneA["Workload Zone A"] AppA end subgraph ZoneB["Workload Zone B"] AppB end Admins --> Bastion --> ZoneA Admins --> Bastion --> ZoneB ZoneA -.isolated first.-x ZoneB

When containment is applied:

Workload‑to‑workload trust is severed
Management access remains intact
Egress inspection may be relaxed to preserve visibility

That’s not weakness, that’s control.

Gotchas & Edge Cases

Relaxing egress inspection does increase short‑term risk that risk must be bounded and time‑limited
Attackers may attempt to exploit relaxed paths but defender lockout is usually worse
Platform dependencies (DNS, identity, logging) often bypass intended failure order
“Temporary” containment rules have a habit of becoming permanent scars

Predictable failure requires ongoing review, not just good intent.

Best Practices

Decide and document which control fails first
Treat centralised inspection as conditional under stress
Keep defender access paths simple and isolated
Avoid deep dependency chains in security enforcement
Assume containment will be executed by tired humans

🍺

Brewed Insight: If your network only behaves safely when every control is intact, it isn’t resilient, it’s fragile. Predictable failure means choosing control over coverage when it matters most.

Learn More

When Your Network Trust Model Stops Matching Your Org Chart

Thu, 28 May 2026 00:00:00 +1000

If you’re in an airport or café, you don’t join every open Wi‑Fi network just because your laptop can see it.

You make a trust decision often subconsciously about which networks you’re willing to attach yourself to.

In Azure networking, we routinely forget that same rule.

VNets get peered. Shared services get connected. Temporary exceptions become permanent.
Connectivity is established and trust quietly follows, whether anyone intended it or not.

This post is about what happens when organisational trust and network trust stop lining up and why that gap becomes a long‑term security failure mode.

The Mental Model

Common assumption:

Subscriptions, VNets, and peering boundaries reflect how much we trust different teams and workloads.

Why it breaks:
Azure networking has no concept of intentional trust. It only understands reachability.

If two networks can communicate:

Trust exists
Authority exists
Blast radius exists

Whether that aligns with how your organisation actually thinks about risk is irrelevant to the platform.

Just like Wi‑Fi, the network won’t stop you joining something unsafe it assumes you meant to.

How It Really Works

VNet peering itself is not technically transitive. Azure won’t magically forward traffic through multiple peerings.

But trust becomes transitive in practice through three mechanisms:

Routing
Once networks can exchange routes, traffic paths emerge that were never explicitly designed.
Name resolution
Shared or linked Private DNS zones turn reachability into discoverability a subtle but powerful trust signal.
Shared platform services
Firewalls, Bastion, jump hosts, monitoring agents, outbound NAT these services often sit inside a network that everyone peers to.

Azure does not distinguish between:

“I trust this network with production data”
“I just needed DNS during a migration”

Connectivity is connectivity. Trust is implied.

Real‑World Impact

1. Shared Services VNets Become Trust Authorities

A shared services VNet is often described as “just plumbing”.

In reality, once it is broadly peered, it becomes part of your security boundary.

Anything that can:

Resolve names
Route traffic
Enforce (or bypass) inspection
Act as an administrative entry point

…is no longer neutral infrastructure. It is trusted.

This is not inherently wrong but it is frequently unacknowledged.

2. Trust Outlives the Reason It Was Granted

Most peerings are created for good reasons:

Migrations
Platform integrations
Temporary access
“We’ll clean this up later”

The problem is not the decision, it’s the lack of an expiry.

Years later:

Teams have changed
Workloads have been repurposed
Environments have shifted criticality

The network still enforces yesterday’s trust model with today’s consequences.

3. Subscription Boundaries Provide False Comfort

Subscriptions feel like security boundaries because they align with:

Cost centres
Ownership
RBAC (Role-Based Access Control)

But from a network perspective, once peered, they are irrelevant.

A compromised workload doesn’t care which subscription it lives in only which networks it can talk to.

Implementation Example: Accidental Trust by Connectivity

A familiar pattern:

graph TD Hub[Shared Services VNet] Prod[Production VNet] NonProd[Non-Production VNet] Legacy[Legacy VNet] Hub --- Prod Hub --- NonProd Hub --- Legacy

This diagram looks tidy. Centralised. Sensible.

What it doesn’t show:

That Non‑Prod and Legacy now share a trust anchor with Prod
That Hub failures propagate everywhere
That any misjudgement in Hub affects all environments equally

The network has no way to express “I trust this less”.

Concrete Artefact: Trust With No Intent or Expiry

A typical peering definition:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


resource hubToSpoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
 name: 'hub-to-spoke'
 parent: hubVnet
 properties: {
 remoteVirtualNetwork: {
 id: spokeVnet.id
 }
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: true
 useRemoteGateways: true
 }
}

This resource encodes:

Connectivity
Routing behaviour
Gateway inheritance

What it does not encode:

Why the trust exists
How long it should exist
What level of risk was accepted

From the platform’s perspective, this is a permanent trust relationship.

Gotchas & Edge Cases

Private DNS is a trust amplifier
If a workload can resolve a private endpoint name, someone assumed it was allowed to exist in the same trust domain.
Temporary peerings rarely get removed
Especially those created during incidents or migrations.
Inherited routing bypasses original threat models
UDRs and forced tunnelling often survive long after the assumptions that justified them.
Security reviews skew toward new designs
Drift happens in the parts of the network nobody wants to touch.

Best Practices (Without Turning This Into Segmentation Advice)

Treat network adjacency as a trust decision
If you wouldn’t join an unknown Wi‑Fi network, don’t implicitly trust a VNet just because it’s convenient.
Assume trust decays over time
Every peering should eventually be questioned, even if nothing appears broken.
Design shared services as least‑trusted, not most‑connected
Broad reach does not mean broad trust.
Review trust, not just topology
Ask who is trusted to talk to whom and whether that still matches reality.

🍺

Brewed Insight:

Azure networking can’t truly express trust but it very clearly expresses where we pretend trust exists.

If your network diagram hasn’t changed in years, your trust model almost certainly has just without anyone consciously agreeing to it or documenting it.

Learn More

DNS Is Not Plumbing: The Hidden Network Dependency You’re Already Trusting

Tue, 26 May 2026 00:00:00 +1000

DNS is the most trusted system in your Azure environment that almost nobody consciously designs for.

It’s set up early, it works quietly, and once it’s stable it fades into the background. Years later, entire environments still depend on decisions made when the first virtual network (VNet) was deployed often by people who’ve long since moved on.

That longevity is the problem.

This post isn’t about DNS outages or misconfiguration. It’s about how centralised DNS becomes a hidden security dependency, shaping trust and failure domains long after your network design is considered “done”.

The Mental Model

Common assumption:
DNS is infrastructure plumbing. Centralise it, keep it simple, and it will fade into the background.

Why this misleads:

Centralised DNS does reduce ambiguity. That’s why it’s the right operational choice in most Azure estates.

But reducing ambiguity has a side‑effect:
it creates a single source of assumed correctness.

Once DNS is trusted implicitly:

Applications stop questioning where they connect
Network controls assume names map to the “right” thing
Engineers stop revisiting name ownership and intent

DNS doesn’t just resolve names, it defines who you trust by default.

How It Really Works

Azure treats DNS as an ambient dependency.

Most workloads and platform services:

Resolve names before meaningful network or application validation
Cache DNS results well beyond the moment of resolution
Assume resolver responses are stable and authoritative
Treat successful resolution as proof of legitimacy

Crucially, DNS resolution happens outside most of your explicit security controls. NSGs (Network Security Groups), UDRs (User‑Defined Routes), and firewalls all act after a name has already been trusted.

Once a name exists, what it points to later becomes a powerful and often invisible control surface.

Real‑World Impact

Centralised DNS: Operationally Correct, Security‑Sensitive

Let’s be clear: centralised DNS is usually the least‑bad option.

It provides:

A single control plane
Clearer support boundaries
Faster troubleshooting
Reduced cognitive load during incidents

The risk isn’t centralisation.

The risk is that everything now implicitly trusts that central authority indefinitely.

One stale record, one reused name, or one compromised resolution path can silently redirect traffic without a single firewall rule changing.

Centralisation doesn’t create fragility.
It compresses trust into one place.

Decentralised DNS: Complexity as False Safety

Decentralised DNS often looks safer on paper:

Smaller blast radius
Local ownership
Fewer global dependencies

In practice, it introduces a different and often worse failure mode:

Ambiguous ownership
Inconsistent naming semantics
Environment‑specific behaviour
Debugging paralysis (“where is this even defined?”)

Decentralisation doesn’t remove risk.
It hides it behind complexity and entropy.

DNS Failures Rarely Look Like Outages

Most DNS‑related failures don’t stop systems outright.

They show up as:

Traffic flowing somewhere “unexpected”
Intermittent connectivity issues
Security controls apparently being bypassed
Engineers adding records to “fix” symptoms

These are trust failures, not availability failures.

How This Changes What You Design and Operate

This should change how you think about network trust, not how you configure DNS.

In real environments:

DNS zones outlive VNets, subnets, and teams
Names persist long after their original intent is gone
Centralisation amplifies the consequences of assumption
DNS becomes a de facto security boundary whether acknowledged or not

If DNS is the single source of truth, then its assumed correctness deserves the same scrutiny as firewall policy or identity trust.

Implementation Examples

This series avoids configuration guidance, but visibility matters.

Most engineers are less certain about DNS trust than they think.

Inspect What a VM Actually Trusts

1
2
3
4


az vm show \
 --resource-group rg-app-prod \
 --name vm-api-01 \
 --query "networkProfile.networkInterfaces[0].dnsSettings"

This tells you:

Whether DNS is inherited or explicitly defined
Which resolver IPs the workload actually trusts
Whether that trust was intentional or accidental

Observation is the first step to challenging assumptions.

The Hidden Dependency Pattern

The network path never changes.
Only the meaning of the name does.

Gotchas & Edge Cases

DNS caching masks failures until TTL expiry
Name reuse couples systems across time, not architecture
Platform services may resolve names differently to your expectations
Engineers often fix DNS symptoms instead of revisiting trust

Most dangerous DNS failures are quiet.

Best Practices (Without Configuration)

Treat DNS zones as long‑lived security assets
Assign explicit ownership for every namespace
Review DNS records with the same discipline as firewall rules
Assume DNS failures will be subtle, not catastrophic
Design services to validate what they connect to, not just where

This is posture, not syntax.

🍺

Brewed Insight: Centralised DNS is the right operational choice, which is exactly why its implicit trust is so dangerous when left unexamined.

Learn More

Routing Decisions That Quietly Create Security Gaps

Thu, 21 May 2026 00:00:00 +1000

Routing still feels like plumbing.

You change where packets go, traffic flows again, and the incident closes. Nothing looks less secure. No rules changed. No alerts fired. Yet something fundamental may have shifted not availability, but who is now allowed to talk to whom.

This post is about routing decisions that don’t break connectivity, they quietly break trust boundaries.

The Mental Model

Common assumption:
Routing is a connectivity concern. Security is enforced elsewhere.

Why it breaks:
In Azure, routing determines the effective security perimeter. If a route expands reachability beyond the documented trust boundary, that expansion is a security failure, regardless of intent.

Security controls only matter if traffic actually traverses them. Routing decides whether they ever get the chance.

How It Really Works

Azure evaluates routing before most security controls can apply policy.

User‑defined routes (UDRs) override platform defaults.
Peering enables reachability that security rules often assume is constrained.
Abstractions hide the effective path until it matters.

Azure will faithfully forward packets along any valid route. It does not validate whether that path aligns with your security intent or whether it expands trust beyond what was ever reviewed.

Routing doesn’t just connect networks.
It redefines the trust model the rest of your security stack assumes.

Routing as an Unreviewed Trust Expansion

Convenience Routes

A common change request:

“We just need workload A to reach service B.”

The route gets added. The problem is solved. But if that route enables A to reach everything B can reach, the trust boundary has already expanded.

No firewall rule changed.
But the security posture did.

If reachability grows beyond what was explicitly documented and approved, the routing change itself is the failure not the firewall configuration.

Asymmetric Paths, Invisible Impact

Azure does not enforce symmetric routing.

It’s easy to create designs where traffic passes through inspection on the way out, but returns via a different path governed by system routes or peering behaviour.

From a security perspective, this means:

Enforcement becomes partial
Logs represent only a subset of reality
Policy confidence decays over time

If you can’t explain the full bidirectional path, you can’t reliably define the trust boundary.

Accidental Transitivity

Routing plus peering enables implicit trust chains.

Network A can reach B.
B can reach C.
A can now often reach C even if nobody intended that relationship to exist.

No new security rule was added.
But effective reachability expanded anyway.

Real‑World Impact

This failure mode shows up operationally, not at design time:

Security reviews pass while posture degrades
Controls are correct, the path is not.
Visibility becomes misleading
Logs show inspected traffic, not all possible traffic.
Change risk compounds silently
Each routing change inherits and extends existing trust relationships.
Security ownership blurs
Routing changes feel “network‑only”, but their impact is architectural.

This changes how routing should be treated in production:
as a security‑significant change, not a connectivity tweak.

Implementation Example: A Route That Expands Trust

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


resource appRouteTable 'Microsoft.Network/routeTables@2023-09-01' = {
 name: 'rt-app-subnet'
 location: resourceGroup().location
 properties: {
 routes: [
 {
 name: 'to-shared-services'
 properties: {
 addressPrefix: '10.40.0.0/16'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.20.0.4'
 }
 }
 ]
 }
}

On paper, this sends app traffic through an inspection point.

In practice, this route should be treated as a security failure if:

10.40.0.0/16 contains more than the explicitly intended services
It enables reachability beyond the documented trust boundary
The return path does not traverse the same enforcement points

The route may be technically correct and still security‑incorrect.

Visualising the Trust Shift

flowchart LR A[App Subnet] -->|UDR| F[Inspection Point] F --> B[Shared Services] B --> C[Additional Networks] C -. Implicit Reachability .-> A

The security gap is not the firewall.
It’s the unreviewed expansion of reachability beyond intent.

Gotchas & Edge Cases

Platform‑managed routes may expand reachability without obvious configuration changes.
Multiple route tables create inconsistent trust enforcement across subnets.
Security tooling reports where traffic was seen, not everywhere it could go.

Best Practices

Treat routing changes as trust boundary changes
Document intended reachability, not just IP ranges
Review routes for what they enable, not what they fix
Assume transitivity unless explicitly disproven
If intent and reachability diverge, classify it as a security issue

🍺

Brewed Insight: If routing expands reachability beyond what you can explicitly justify, the design is already insecure even if every security control still looks correct.

Learn More

When the VNet Becomes a Yes‑Man: Over‑Trusted Internal Traffic in Azure

Tue, 19 May 2026 00:00:00 +1000

Most Azure environments don’t fail because someone opened the perimeter too wide.

They fail because inside the network, everything slowly learned it didn’t need to ask anymore.

Reachability became normal. Then expected. Then invisible.

By the time anyone questions it, the network has already answered yes on their behalf.

The Mental Model

Common assumption:

“If traffic is inside the VNet or coming from on‑prem it’s already trusted.”

This isn’t usually stated out loud. It just emerges.

VNets start small. On‑prem connectivity is enabled for migration speed. Shared services need to be reachable. Early workloads benefit from convenience, and nothing breaks.

Why it misleads:
VNets don’t stay small and neither does connectivity intent.

As environments grow, reachability expands faster than understanding. What began as a deliberate exception turns into a default, and “inside the network” quietly becomes shorthand for safe enough.

That’s not a security philosophy problem.
It’s a network failure caused by trust inheritance.

How It Really Works

Azure VNets are routing domains, not trust domains.

They provide:

Layer‑3 connectivity
Flat reachability by default
No concept of workload sensitivity or intent

Azure is doing exactly what it’s designed to do.

The failure happens when connectivity is treated as authorisation especially across boundaries that were never meant to be peers.

Over time, this pattern emerges:

On‑prem networks can reach most VNets
New workloads inherit that reachability automatically
No explicit decision is made because none is required

At that point, the network isn’t enforcing intent.
It’s amplifying convenience.

The Real Question You’re Facing

You’re not choosing between open and locked‑down networking.

You’re choosing between:

Implicit trust via reachability, or
Explicit trust via declared intent

If on‑prem can reach everything simply because it’s on‑prem, the network has already made a trust decision it just didn’t document it.

A Necessary Reframe: On‑Prem Is a Zone, Not a Peer

In a mature Azure environment, on‑prem should not be treated as “just another VNet”.

It is a distinct network zone with different ownership, lifecycle, and failure characteristics.

A defensible default looks like this:

On‑prem can reach shared services by default.
Workload networks must opt‑in.

This isn’t about assuming compromise.
It’s about preventing ambient trust from spreading via routing.

Real‑World Impact

This failure mode shows up operationally long before any incident.

Design impact

New workloads become reachable from on‑prem without discussion
Architects can’t clearly state why certain paths exist
Shared services quietly become transit points

Operational impact

Connectivity reviews focus on NSGs instead of intent
Change risk increases because blast radius is unclear
Removing access is harder than granting it ever was

Security impact

Internal boundaries blur
Lateral movement becomes a property of the network
Containment relies on “nothing changing” rather than design

The network didn’t break suddenly.
It drifted and no one noticed.

Implementation Examples

What Over‑Trust Looks Like at Scale

After a few years of growth, many environments resemble this:

graph TD OP[On‑Prem Network] HUB[Shared Services VNet] APP1[App VNet] APP2[App VNet] DATA[Data VNet] OP --- HUB OP --- APP1 OP --- APP2 OP --- DATA HUB --- APP1 HUB --- APP2

Nothing here violates Azure best practices.

The failure is behavioural:

On‑prem reachability is assumed, not justified
New VNets inherit access automatically
No one can say which paths are intentional

How the Failure Creeps In

A typical peering or gateway configuration (simplified):

1

allowVirtualNetworkAccess: true

This isn’t wrong.

But over time, it’s interpreted as:

“Anything internal can probably talk to this.”

That assumption scales faster than architecture diagrams.

Gotchas & Edge Cases

Private endpoints don’t fix this
They often reinforce the idea that “private” equals “safe”, even as reachability expands.
Peering intent fades faster than peering configs
The network remembers decisions long after teams forget why they were made.
Change velocity accelerates trust drift
Especially when new workloads are created by teams far from the original design.

Best Practices (Without Tooling)

Staying within network design, not enforcement:

Define where on‑prem can reach by default and write it down
Treat workload reachability as an opt‑in decision
Periodically review which paths exist purely because they’re easy
Design shared services as intentional choke points, not accidental hubs

These are design disciplines, not firewall strategies.

🍺

Brewed Insight: If a new workload can be reached from on‑prem without anyone explicitly deciding that it should, the network has already failed even if nothing is broken yet.

Learn More

When ‘Secure by Design’ Fails in Production

Thu, 14 May 2026 00:00:00 +1000

“Secure by design” is one of those phrases that sounds definitive.

It implies an end state that if you get the architecture right up front, security becomes a property of the system rather than something you constantly fight.

In Azure production environments, that belief doesn’t just fail.
It quietly dissolves, one well‑intentioned change at a time.

Not because engineers forget how to design securely but because the assumptions that made the design secure are nobody’s job to preserve.

The Mental Model

Common assumption:
Security fails when controls are missing, misconfigured, or ignored.

Why it misleads:
In mature Azure estates, most controls exist.
The failure happens elsewhere when security assumptions decay across organisational and technical boundaries.

“Secure by design” assumes:

stable ownership
stable dependencies
stable trust boundaries

None of those survive scale.

How It Really Works

In enterprise Azure environments, ownership is divided by control plane, not by security outcome.

Typically:

Network teams own connectivity
(VNets, peering, UDRs, Private Endpoints)
System administrators own operations
(VM access, patching, agents)
DBAs own data platforms
(SQL configuration, firewall rules)
Application teams own app behaviour and data usage
(SDKs, outbound calls, feature flags)
Security teams own policy
(standards, approvals, alerts not packet flow)
Microsoft owns the platform but not how you use it

Everyone owns something.
No one owns the security assumptions that exist between these domains.

Those assumptions include things like:

“This app cannot laterally reach other environments”
“All outbound traffic is inspected”
“Only intended consumers can reach this data store”

They are real.
They are critical.
And they are almost never explicitly owned.

Real‑World Impact

This is where “secure by design” fails in production.

Not through a single bad change, but through coordinated innocence:

A network team enables VNet peering “for integration”
A DBA adds a firewall exception “to unblock delivery”
An app team introduces a new dependency “for a feature”
A security team approves because policy conditions are met

Each change is defensible in isolation.
Collectively, they invalidate the original threat model.

At small scale, this works because:

people remember why things exist
blast radius is limited
informal review catches mistakes

At enterprise scale:

assumptions outlive the people who made them
undocumented dependencies become business‑critical
trust paths multiply faster than anyone models them

Security doesn’t fail loudly.
It drifts.

Implementation Examples

Consider a common shared‑services pattern.

Original design intent

graph TD A[App VNet] -->|Peering| B[Shared Services VNet] B --> C[Azure Firewall] C --> D[Internet]

Security assumption:
All app egress is inspected and controlled centrally.

Two years later

graph TD A[App VNet] -->|Peering| B[Shared Services VNet] A --> E[Another App VNet] E --> F[Private Endpoint] F --> G[PaaS Service]

Nothing here violates Azure’s rules.

But several assumptions are now false:

Traffic no longer consistently traverses the firewall
DNS resolution now determines reachability
App VNets can reach more than originally intended
Firewall logs no longer represent the full picture

A subtle but powerful example is VNet peering itself:

1
2
3
4
5
6
7


resource vnetPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
 name: 'app-to-shared'
 properties: {
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: true
 }
}

That single flag establishes permanent lateral trust unless explicitly revisited.

It is rarely reviewed again — because no team owns the assumption it creates.

How would this change something I design, deploy, or operate?
You stop treating connectivity as reversible plumbing and start treating it as a long‑lived security commitment.

Gotchas & Edge Cases

Private Endpoints don’t “break security” — they break assumptions
Especially when routing, DNS, and inspection models were designed first
Logging creates false confidence
Firewall and NSG flow logs only tell the truth about traffic they actually see
Policy enforces existence, not intent
A rule can be compliant and still dangerous
Temporary exceptions become structural dependencies
And nobody volunteers to remove them

Best Practices

Not prescriptive steps — but mindset shifts that survive scale:

Assume security assumptions will decay Design review is not a one‑time event
Treat network changes as security changes by default Even when raised by non‑security teams
Minimise implicit trust Especially lateral trust created by peering and shared DNS
Make connectivity decisions expensive to forget If you can’t explain why it exists, it shouldn’t be permanent

🍺

Brewed Insight: Secure‑by‑design fails not because no one owns security, but because no one is accountable for preserving security assumptions as the organisation fragments. In Azure, drift isn’t an exception — it’s the default behaviour.

Learn More

The failure mode described here doesn’t come from a single misconfiguration, it emerges from how Azure architectures divide responsibility across teams.

These references are useful not because they solve that problem, but because they implicitly assume it:

Azure Shared Responsibility Model
Clearly defines where Microsoft’s responsibility ends and where ungoverned shared accountability begins.
https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility
Azure Zero Trust Architecture (Azure)
Highlights the mismatch between static network trust and continuous verification models.
https://learn.microsoft.com/security/zero-trust/azure-infrastructure-overview
Hub‑Spoke Network Reference Architecture
A common starting point whose security assumptions rarely survive enterprise‑scale operation without explicit ownership.
https://learn.microsoft.com/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

Designing for Fewer East–West Options (Not Zero)

Tue, 12 May 2026 00:00:00 +1100

If you’ve ever tried to clean a cluttered bench mid‑shift, you know the trick isn’t perfection it’s removing places where clutter can spread.

East–west traffic is the same.

Once an attacker is inside your Azure estate, the problem isn’t whether lateral movement is possible.
It’s how many plausible directions they can go next.

Designing for zero east–west traffic is fantasy.
Designing for fewer options deliberately is architecture.

The Mental Model

Common assumption:
“Internal connectivity is fine. We’ll trust it unless there’s a reason not to.”

Why it breaks:
This assumes internal networks are stable trust zones. They aren’t.

In real Azure estates, east–west paths accumulate quietly:

A new VNet peering to “unblock delivery”
A Private Endpoint added for convenience
A shared services VNet that slowly becomes transit infrastructure

Each change feels reasonable in isolation.
Collectively, they create unbounded lateral optionality.

The core mistake isn’t trusting internal traffic.
It’s failing to ask: from this point of compromise, where can I go next?

How It Really Works

A more useful mental model is bounded lateral radius.

An Azure network has meaningfully reduced east–west risk when compromise of a single workload results in a small, predictable set of lateral paths not an open‑ended search space.

This is not about neat diagrams or tidy segmentation.
It’s about outcomes from the attacker’s starting point.

If an attacker lands in one subnet:

Can they only reach one or two specific services?
Or do they quickly discover multiple VNets, shared dependencies, and alternate routes?

East–west risk grows when:

Connectivity is cheap and reversible
Shared services relay traffic instead of terminating it
New paths don’t require justification

Azure makes all of this easy, which is why architecture has to be intentional.

Real‑World Impact

Designing for fewer east–west options changes how you think about:

Blast radius
Networks are designed around where compromise stops, not where workloads live.
Shared dependencies
Anything broadly reachable is inside the blast radius by definition.
Change conversations
Adding connectivity becomes a security‑relevant decision, not plumbing.

This directly answers the practical question:

How would this change something I design, deploy, or operate?

You stop optimising for convenience first and start optimising for predictable containment.

Implementation Examples

Make Lateral Paths Explicit and Rare

A hub‑and‑spoke model only helps if the hub does not quietly become a router.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


resource hubToSpoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
 name: 'hub-to-app-spoke'
 parent: hubVnet
 properties: {
 remoteVirtualNetwork: {
 id: spokeVnet.id
 }
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: false
 allowGatewayTransit: false
 useRemoteGateways: false
 }
}

This snippet isn’t about syntax.
It’s about default behaviour.

Two flags here are doing real containment work:

allowForwardedTraffic: false
allowGatewayTransit: false

Removing either one does not usually break functionality.
What it breaks is bounded lateral radius.

With forwarded traffic or gateway transit enabled, a compromised spoke doesn’t just reach the hub it can use the hub to explore elsewhere. The hub becomes a lateral movement amplifier rather than a boundary.

This is how east–west risk is usually introduced:
not by adding new connectivity, but by failing to prevent transit.

Treat Shared Services as a Containment Trade‑Off

A broadly peered “shared services” VNet is not neutral.

Shared services VNets almost always expand lateral radius, often dramatically.

If a service is reachable from many workloads:

It sits inside many blast radii
It becomes a lateral pivot, not just a dependency

Operational necessity doesn’t change this reality.

If a service must be shared, then the blast radius is knowingly widened and should be treated as a high‑risk architectural decision, not a default pattern.

Private Endpoints: Visibility, Not Immunity

Private Endpoints don’t break the bounded‑radius model.
They expose where it isn’t being enforced.

Each Private Endpoint is an explicit east–west path:

It crosses VNets
It expands reachable surface area
It persists quietly

If you can’t explain why a Private Endpoint exists and which blast radius it belongs to then lateral radius is already unbounded.

Visualising Bounded Lateral Radius

flowchart LR A[App VNet] -->|Explicit| B[API VNet] B -->|Private Endpoint| C[PaaS Service] A -. No direct path .-> C A -. No peering .-> D[Admin VNet]

From App VNet, there is one obvious direction.

That’s the goal:

Not isolation
Not zero‑trust theatre
Predictable movement

Gotchas & Edge Cases

Shared services creep
What starts as DNS or automation often becomes transit.
Private Endpoint sprawl
Endpoint count is less important than endpoint intent.
Delivery pressure
If adding a new east–west path is easy, your architecture is optimised for attackers, not operators.

Best Practices

Design networks around points of compromise, not environments
Assume shared reachability expands blast radius unless proven otherwise
Make east–west connectivity nameable and explainable
Prefer terminating connections over relaying ones

A simple test:

If you can’t name every lateral path out of a workload without querying tooling, optionality hasn’t been reduced, it’s just been obscured.

🍺

Brewed Insight: You don’t control lateral movement by drawing boundaries.
You control it by deciding, deliberately, how much choice you’re willing to give an attacker.

Learn More

Hybrid East–West: When Two Networks Become One Problem

Thu, 07 May 2026 00:00:00 +1100

Hybrid networking usually starts with good intentions.

A site‑to‑site VPN or ExpressRoute is approved to “unlock value”. Azure workloads need to talk to on‑prem systems, operations need visibility, shared services need reach. The diagram still shows two boxes, so it feels contained.

But the moment east–west traffic crosses that link, containment stops being an architectural fact and becomes an assumption.

And assumptions don’t survive attackers.

The Mental Model

Common assumption:
On‑prem and Azure are separate security domains that just happen to be connected.

Why it breaks:
East–west traffic doesn’t understand organisational boundaries. Once routing and DNS align, hybrid connectivity collapses those domains into a single lateral movement surface selectively, but decisively.

Hybrid doesn’t “extend” your network.
It redefines adjacency.

How It Really Works

Hybrid east–west behaves less like cross‑environment communication and more like internal traffic with extra hops.

Three forces make this unavoidable.

1. Routing Turns Distance into Trivia

From a packet’s perspective, an RFC1918 prefix reachable via ExpressRoute or VPN is just another route.

If Azure workloads can route to on‑prem subnets, then adjacency exists regardless of intent, documentation, or team boundaries.

This is where many designs fail quietly: segmentation may exist within environments, but hybrid routing stitches those segments together in ways no single team models end‑to‑end.

2. DNS Collapses Discovery

Shared DNS is the most underestimated hybrid risk.

Private DNS zone links, conditional forwarders, split‑horizon records, all introduced for operability unify discovery across environments. Once names resolve, targets are discoverable. Once discoverable, they are reachable by design.

Hybrid DNS rarely mirrors trust boundaries. It mirrors convenience.

3. Legacy Trust Survives the Move

This is the uncomfortable part.

Treating Azure VNets as an extension of the on‑prem “internal network” is no longer a risk it is an architectural failure.

That failure usually shows up as:

Broad RFC1918 route advertisement
Shared DNS namespaces without containment intent
Implicit trust based on IP origin rather than workload purpose

These assumptions made sense in legacy estates. Carrying them into Azure turns hybrid connectivity into an amplifier for lateral movement.

Real‑World Impact

This materially changes how you design, deploy, and operate hybrid estates.

Containment Stops at the Wrong Places

If a compromised Azure workload can:

Resolve on‑prem service names
Route to broad on‑prem prefixes
Reach shared or management services

Then containment is no longer environment‑scoped. It’s estate‑wide.

At that point, “hybrid” is not a boundary it’s a corridor.

Blast Radius Expands by Default

Most hybrid designs are asymmetric:

Azure workloads gain broad on‑prem reach
On‑prem systems only require narrow Azure access

That imbalance is perfect for lateral movement out of Azure and into legacy environments where controls are weakest and trust is highest.

Change Control Quietly Becomes a Security Decision

Adding a VNet peering, linking a DNS zone, or advertising a new route can silently expand the attack surface.

These changes are often treated as networking hygiene, not trust‑boundary modifications.

That mismatch is structural, not procedural.

Implementation Examples

Visualising the Hybrid East–West Surface

The tunnel isn’t the risk.
Everything that becomes reachable because of it is.

flowchart LR A[Azure Workload VNet] B[Azure Shared Services VNet] C[On‑Prem App Network] D[On‑Prem Infra Network] A --> B B --> C C --> D A -. DNS Resolution .-> C A -. Routing .-> D

Once routing and DNS align, lateral movement doesn’t care which side of the cloud boundary it starts on.

Route Reality Check (Azure CLI)

This isn’t about configuring routes it’s about recognising adjacency.

1
2
3


az network nic show-effective-route-table \
 --resource-group rg-prod \
 --name nic-app-01

If an application NIC shows broad on‑prem prefixes with a Virtual network gateway next hop, the question is no longer “is this needed?”.

It’s “why is this workload adjacent to legacy infrastructure at all?”

That output isn’t just diagnostic data.
It’s evidence of a trust decision already made.

Gotchas & Edge Cases

“Doesn’t This Explode Cost and Complexity?”

Yes, it can.

Rejecting universal hybrid adjacency often means:

More deliberate workload placement
Fewer but more intentional hybrid crossing points
Increased up‑front design effort

What it does not automatically mean:

One tunnel per workload
Dozens of ExpressRoutes
Infinite network sprawl

Most estates don’t suffer because they have too many hybrid connections.
They suffer because everything is allowed to use the same one.

Flat hybrid designs trade visible complexity for invisible blast radius. The cost doesn’t disappear — it just shows up later, under incident response and compensating controls.

“But It’s ExpressRoute, It’s Private”

Private doesn’t mean constrained.

ExpressRoute often increases east–west risk because it:

Encourages broader route propagation
Reduces perceived scrutiny
Becomes the default path for “just make it work” connectivity

The transport isn’t the issue. Reachability is.

Asymmetric Visibility Persists

Hybrid east–west paths routinely cross tooling boundaries:

Azure flow logs on one side
Legacy monitoring on the other

No single team sees the full lateral path. That blind spot is architectural, not operational.

Best Practices

Treat hybrid routing and DNS changes as trust‑boundary decisions
Minimise advertised prefixes, especially management and shared services
Avoid universal hybrid adjacency by default; justify it explicitly
Review effective routes from workload NICs, not diagrams
Accept that reducing blast radius may increase design effort and choose it anyway

This isn’t about blocking traffic.
It’s about being intentional about who becomes adjacent to what.

🍺

Brewed Insight: Hybrid connectivity doesn’t give attackers new capabilities it gives them continuity.
If everything is hybrid‑adjacent, then cloud and on‑prem aren’t environments anymore they’re just terrain.

Learn More

Segmentation vs Reality: Why East–West Risk Persists

Tue, 05 May 2026 00:00:00 +1100

Segmentation looks solid right up until something breaks.

Not a pentest.
Not a red‑team exercise.
A real outage, at 2am, with customers waiting.

That’s when the boundaries you designed start bending and some of them never snap back. East–west risk persists not because teams ignore segmentation, but because operations reward connectivity long after intent is forgotten.

The Mental Model

Common assumption:
“If environments and tiers are segmented, lateral movement is constrained.”

Why it breaks:
Segmentation is usually designed as a static layout, while real systems are dynamic under pressure. Once compromise is assumed, the question isn’t whether boundaries exist, it’s whether they survive shared services and incident response.

Most don’t.

How It Really Works

In real Azure estates, segmentation fails less often because of missing controls and more often because of where trust accumulates.

Two forces dominate:

Shared services that span environments by design
Operational exceptions made under urgency and never undone

Neither feels risky in isolation. Together, they flatten the estate.

Where teams think enforcement lives

Boundaries are often assumed to be enforced by:

VNets and peering layouts
Subscription separation
“This is prod, that isn’t”

But enforcement actually emerges from who can reach what during normal operations especially automation and responders. That reach expands steadily unless actively constrained.

Real‑World Impact

Example 1: The Shared Build Agent That Becomes the Bridge

A central CI/CD build agent subnet deploys to multiple application VNets across prod and non‑prod. It needs access to:

Source artefacts
Deployment endpoints
Management APIs

From an ops perspective, this is sensible. From a compromise perspective, it’s decisive.

If a single build agent VM or pipeline identity is compromised, segmentation between environments becomes largely theoretical. East–west reach isn’t gained through clever movement it’s inherited.

This is segmentation collapsing by design convenience, not misconfiguration.

Example 2: Incident Response Exceptions That Never Roll Back

During a production incident, teams temporarily allow additional east–west access to diagnose or stabilise the system. The change is:

Time‑boxed in intent
Permanent in practice

No one updates the diagram. No one re‑validates the boundary. The estate now contains a path that only exists because things once went wrong.

Multiply this across incidents, migrations, and staff turnover, and segmentation slowly becomes an archival concept.

Implementation Examples

This isn’t about adding more rules. It’s about making segmentation intent explicit and reviewable, especially around shared services.

Encoding segmentation intent for shared services

Below is a deliberately lightweight Bicep example that tags a shared service VNet with declared blast radius. This does not enforce isolation it makes erosion visible.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


resource sharedServicesVnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
 name: 'vnet-shared-services'
 location: resourceGroup().location
 tags: {
 role: 'shared-services'
 permittedEnvironments: 'prod,nonprod'
 eastWestRisk: 'high'
 owner: 'platform-team'
 }
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.10.0.0/16'
 ]
 }
 }
}

Why this matters operationally:

Shared services are explicitly acknowledged as risk concentrators
Platform teams can be challenged on blast radius during reviews
Drift between “should reach” and “does reach” becomes auditable

Segmentation that can’t be reasoned about programmatically won’t survive growth.

What east–west reality often looks like

flowchart LR BuildAgent[Shared Build Agent] ProdApp[Prod App Tier] NonProdApp[Non‑Prod App Tier] IncidentAccess[Temporary Incident Access] BuildAgent --> ProdApp BuildAgent --> NonProdApp IncidentAccess --> ProdApp

None of these paths are accidental. That’s the point.

Gotchas & Edge Cases

Shared services are rarely treated as first‑class risk domains
They’re optimised for reliability and speed, not containment.
Incident changes bypass architecture review by necessity
If rollback isn’t operationally enforced, it won’t happen.
Segmentation reviews usually happen pre‑deployment
East–west risk emerges post‑incident and post‑migration.

Best Practices

Treat shared services as deliberate blast‑radius expanders, not neutral infrastructure.
Assume any access granted during incidents will persist unless actively removed.
Regularly review segmentation starting from shared services outward, not from app tiers inward.
Prefer fewer boundaries that survive incidents over many that don’t.

This is not about perfection, it’s about survivability under stress.

🍺

Brewed Insight: Segmentation rarely fails at design time.
It fails when convenience and urgency quietly outvote intent and no one is accountable for restoring the boundary.

Learn More

How Azure Networking Quietly Enables Lateral Movement

Thu, 30 Apr 2026 00:00:00 +1100

Most Azure estates don’t feel flat.

They have hubs, spokes, subnets, and diagrams that suggest intent and order. On paper, things look segmented. Contained. Reasonable.

Yet once something unwanted lands inside, movement often feels frictionless like walking through an open-plan office where every door politely steps aside.

That isn’t because someone forgot a firewall rule.
It’s because Azure networking is doing exactly what it was designed to do.

The Mental Model

Common assumption:
Internal Azure networks are segmented unless you explicitly connect them.

Why it breaks:
Azure optimises for reachability, symmetry, and operational correctness. Once you create connectivity, Azure assumes you meant it, and it works hard to preserve stable, symmetric paths between everything involved.

East–west movement isn’t an attacker trick.
It’s an architectural outcome.

How It Really Works

Let’s talk about behaviour, not marketing diagrams.

Symmetric hub routing is the real enabler

Azure VNet peering itself is non‑transitive. On its own, it doesn’t flatten anything.

Transitivity appears when architects (often correctly, at the time):

Centralise routing through a hub
Introduce Azure Firewall or NVAs
Apply default UDRs (0.0.0.0/0) from spokes to the hub
Expect symmetric paths for reliability and troubleshooting

At that point, the hub stops being a boundary and becomes a routing fabric.

Once symmetry is restored, spoke‑to‑spoke reachability isn’t an accident it’s the inevitable result of a design optimised for correctness.

Azure preserves paths aggressively

Azure system routes and platform behaviour:

Prefer the most specific prefix
Preserve return paths when they exist
Avoid blackholing traffic unless explicitly instructed

This is excellent for application uptime.
It’s also excellent for internal exploration.

If a packet can get there and come back, Azure will try very hard to keep that path stable.

A Hard Admission

I’ve implemented symmetric hub routing myself more than once.

It solved real problems:

Predictable traffic flows
Fewer asymmetric failures
Easier troubleshooting at 2am

What I underestimated wasn’t the firewall or the rules.
It was how completely Azure erased any remaining sense of internal boundary once symmetry was restored.

The design was correct.
The blast radius was just larger than I intended.

Real‑World Impact

This isn’t theoretical. It changes outcomes.

Design
Symmetric hub routing collapses routing domains. Once in a spoke, the rest of the estate becomes discoverable by default.

Reliability
The same paths that propagate traffic propagate failures security incidents and outages share infrastructure.

Security
Lateral movement becomes a question of which routes exist, not which controls failed.

Cost
Broad east–west flows quietly consume firewall throughput and bandwidth even during normal operation.

Practical anchor:
This should change when and how freely, you restore routing symmetry in your designs.

Implementation Example

The “standard” hub‑and‑spoke pattern

flowchart LR SpokeA --> Hub SpokeB --> Hub Hub --> SpokeA Hub --> SpokeB Hub --> SharedServices SharedServices --> Hub

No direct peering between spokes.
Yet full spoke‑to‑spoke reachability exists via the hub.

The UDR that makes it inevitable

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


resource spokeRouteTable 'Microsoft.Network/routeTables@2023-09-01' = {
 name: 'rt-spoke-default'
 location: resourceGroup().location
 properties: {
 routes: [
 {
 name: 'default-to-hub'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.0.0.4' // Hub firewall or NVA
 }
 }
 ]
 }
}

This single route:

Restores symmetry
Makes the hub a transit router
Removes natural routing boundaries between spokes

Operationally clean.
Architecturally expansive.

Gotchas & Edge Cases

Peering flags don’t save you
AllowForwardedTraffic = false doesn’t help once routing is reintroduced elsewhere.
Gateway transit magnifies the effect
Shared gateways flatten routing domains even further.
Private Endpoints don’t change this
They reduce exposure, not reachability. Routes still define movement.

Guidance for Future Designs

This isn’t about banning hubs or symmetry. It’s about intent.

Treat routing symmetry as privileged

In Azure, symmetric routing is not neutral.
It is a privileged capability that should be granted deliberately and narrowly.

If symmetry isn’t required, let paths fail closed.

Design routing domains, not just VNets

VNets and spokes are implementation details.
Routing domains define blast radius.

If two workloads don’t need to talk both ways, they don’t belong in the same routing domain regardless of how tidy the diagram looks.

Make hubs earn their reach

Centralised hubs trade convenience for scale including the scale of failure.

Every east–west path enabled by a hub should be justified.
“Operational simplicity” alone is not a sufficient reason.

Defer symmetry, don’t default to it

Today, I treat symmetric hub routing as an optimisation to be earned late not a baseline assumed early.

That single shift changes how networks age under pressure.

🍺

Brewed Insight: Azure rewards correctness and connectivity.
Restraint is something you have to design against the platform on purpose.

Learn More

Trust Boundaries That Exist Only in Diagrams

Tue, 28 Apr 2026 00:00:00 +1100

Most Azure environments are beautifully segmented, on paper.

Prod, non‑prod, shared services, landing zones. Clean lines. Sensible colours. Everyone agrees where the trust boundaries are supposed to be.

Then a single workload gets compromised, and suddenly the attacker has options.

Not because anyone misconfigured a firewall.
Because the boundary never existed at runtime.

The Mental Model

Common assumption:

“Different subscriptions, VNets, or environments imply different trust levels.”

Why it breaks:
Azure does not enforce trust.
Azure enforces reachability.

A trust boundary only exists where no routable path exists at runtime.
If packets can flow, trust already exists regardless of ownership, intent, or documentation.

Everything else is risk management dressed up as segmentation.

How It Really Works

Azure networking behaves like software, not policy.

Once east–west reachability is present:

The platform routes packets without regard for environment labels
Subscriptions are ignored entirely by the data plane
VNets become peers the moment routing allows it
Workloads assume whatever the network allows them to see

What architects often describe as “implicit trust” is actually emergent trust — created unintentionally by routing decisions.

Three types of trust are routinely conflated:

Trust Type	What it governs	What it does not govern
Administrative trust	Who can deploy or change resources	Runtime communication
Network trust	IP reachability	Workload intent
Workload trust	What the application expects	Network exposure

Only one of these determines lateral movement potential: network reachability.

Real‑World Impact

This is why east–west traffic is the real attack surface.

In live Azure estates, “diagram‑only” boundaries collapse into:

Shared services VNets acting as lateral movement bridges
Hub‑and‑spoke designs where isolation is assumed, not enforced
Environment separation that disappears once routing converges
Legacy peerings that quietly expand blast radius year after year

From an attacker’s perspective, the estate is mapped by a single question:

“What IP space can I reach next?”

If the answer spans environments, subscriptions, or tiers — the boundary was imaginary.

How would this change something I design, deploy, or operate?
You stop asking who owns this network and start asking what can this workload actually reach at runtime.

Implementation Examples

The Invisible Trust of VNet Peering

Nothing here declares trust:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


resource spokeToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
 name: 'spoke-to-hub'
 parent: spokeVnet
 properties: {
 remoteVirtualNetwork: {
 id: hubVnet.id
 }
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: true
 useRemoteGateways: false
 }
}

But at runtime:

Routes are exchanged
IP reachability exists
Any listening service becomes a lateral movement candidate

The trust relationship is not configured.
It emerges.

Peering itself isn’t “transitive” — but reachability becomes effectively transitive once routing and shared paths exist.

That distinction matters operationally, not architecturally.

Visualising Trust vs Reachability

Most diagrams show connectivity.
Attackers care about paths.

graph LR A[Prod App VNet] B[Non-Prod App VNet] C[Shared Services VNet] A --- C B --- C style A fill:#cce5ff style B fill:#d5f5e3 style C fill:#f9e79f

Intended trust:

Prod trusts Shared
Non‑Prod trusts Shared
Prod does not trust Non‑Prod

Runtime reality:

Prod ↔ Shared ↔ Non‑Prod
A routable path exists
Therefore, trust exists

The network does not infer your intent.
It enforces physics.

Gotchas & Edge Cases

Subscription boundaries have zero impact on packet flow
Environment naming is invisible to the data plane
“Temporary” peerings almost never get removed
Shared services quietly accumulate the widest blast radius
Once breached, containment follows routing — not diagrams

None of this requires negligence.
It emerges from reasonable defaults applied over time.

Best Practices

Treat absence of reachability as the only real trust boundary
Assume any routable east–west path will eventually be abused
Design shared services as risk concentrators, not neutral hubs
Regularly review effective reachability, not intended architecture
If two environments must not trust each other, they must not be routable — full stop

This is Assume Breach applied to network design, not policy.

🍺

Brewed Insight:

If a trust boundary isn’t enforced by the platform at runtime, it isn’t a boundary — it’s a diagram annotation.

Good Azure architecture starts by being honest about where packets can actually go.

Learn More

East–West Traffic Is Where Cloud Incidents Actually Spread

Thu, 23 Apr 2026 00:00:00 +1100

Most cloud incidents don’t escalate because someone was clever at breaking in.

They escalate because the environment was already helpful once they arrived.

If you’ve ever sat in a post‑incident review thinking, “I didn’t realise those systems could talk to each other”, you’ve already seen where the real damage happens east–west traffic.

The Mental Model

Common assumption:
“Internal traffic is safer. The perimeter is where risk lives.”

Why it breaks:
Under an Assume Breach mindset, internal reachability is the primary blast‑radius multiplier. East–west paths are rarely designed to contain failure. They’re designed to keep systems working as requirements evolve.

That makes them durable, invisible, and dangerous under compromise.

How It Really Works

In Azure estates, east–west traffic isn’t centrally planned. It emerges.

It emerges from:

Incremental connectivity added to unblock delivery
Runtime dependencies discovered after go‑live
Legacy behaviour preserved to avoid outages
Organisational pressure to keep things moving

Each individual decision is reasonable. Collectively, they form traversal paths no one set out to design, but which attackers can rely on.

The platform doesn’t distinguish between “architectural intent” and “operational necessity”. Routing and reachability follow what exists now, not what was drawn.

Real‑World Impact

Here’s a common post‑incident pattern.

A business application is described and diagrammed, as a classic three‑tier design: web, app, data. During a containment exercise, outbound connectivity from the app tier back to the web tier is disabled as a scream test.

Production breaks.

Investigation shows the app tier is:

Writing files back to the web tier for user access, and/or
Responding directly to users under certain workflows

None of this was malicious. All of it was required.

The bidirectional connectivity wasn’t an accident it was an operational dependency that formed after the original design. Over time, that dependency became untouchable.

From a breach perspective, compromise of the app tier now inherently includes a path back to user‑facing surfaces without exploiting anything new.

How would this change something I design, deploy, or operate?
You stop trusting tier labels and start validating directional behaviour. “Internal” no longer means “contained”.

Structural Reasons East–West Paths Persist

These paths survive because they acquire protection through necessity:

They’re justified post‑hoc as “how the app works”
They’re undocumented because they evolved organically
They can’t be removed without immediate impact
They cross boundaries that were never designed as security controls

The phrase that shows up in reviews is telling: “unexpected but required”.

Once something is required, it stops being questioned and becomes architectural fact.

Implementation Examples

Architecture View: How Runtime Behaviour Overrides Design

flowchart LR U[User] --> W[Web Tier] W --> A[App Tier] A --> D[Data Tier] A -->|Operational Dependency| W style A fill:#f5f5f5 style W fill:#f5f5f5

The diagram says “three tiers”.
The runtime says “bidirectional”.

Attackers only need to follow what already works.

Gotchas & Edge Cases

“Same app” is not a containment boundary
Lateral movement doesn’t care about application ownership.
Scream tests reveal truth late
By the time you can’t disable a path, it’s already structural.
Directionality is rarely validated
Engineers confirm that traffic flows, not who initiates it.
Removal risk entrenches exposure
The harder a path is to remove, the more dangerous it becomes under breach.

Best Practices

Without touching specific controls:

Treat east–west connectivity as intentional architecture, not background plumbing
Validate direction of initiation, not just reachability
Assume every “temporary” dependency will outlive its justification
Design internal paths so they can fail without collapsing user‑facing surfaces

Containment is a design outcome, not a firewall feature.

🍺

Brewed Insight: In cloud environments, lateral movement usually isn’t enabled by attackers, it’s enabled by applications quietly evolving past their original design.

Learn More

Networks That Fail Safely Under Breach Conditions

Tue, 21 Apr 2026 00:00:00 +1100

Most Azure networks are designed like espresso machines: finely tuned, pressure‑balanced, and very unhappy when you pull the wrong lever.

Under steady state, that precision feels like quality engineering.
Under breach conditions, it often turns out to be fragility.

Assume breach changes the question from “How do I keep them out?” to a much less comfortable one:

“What happens to my network when someone is already in and I start breaking things on purpose?”

The Mental Model

Common assumption:
If a network is secure enough to prevent compromise, it will behave sensibly once compromised.

Why it breaks:
Most Azure networks are optimised for normal operations:

Shared route tables for consistency
Centralised inspection paths
Broad east‑west reachability “inside the VNet”
Security controls designed to be added, not activated

These choices feel clean and efficient, right up until containment is required.
At that point, the network stops being infrastructure and becomes a live incident tool.

Networks that were never designed to fail don’t fail gracefully. They fail globally.

How It Really Works

Once breach is assumed, the network’s job changes.

It is no longer primarily a preventative control.
It is an active constraint system that must support human decision‑making under stress.

Fail‑safe networks behave differently in four key ways:

Localised trust – Compromise in one subnet does not imply reachability elsewhere.
Predictable degradation – Containment actions reduce capability in known, bounded ways.
Asymmetric pain – Attackers lose freedom faster than defenders lose visibility.
Defender‑first control – Emergency actions don’t depend on shared components that attackers may already influence.

The absence of these traits is what makes a network brittle, regardless of how “secure” it looks on a diagram.

Real‑World Impact

This reframes several everyday Azure design decisions.

Shared Route Tables Are Actively Unsafe Under Breach

This is the strongest claim in this post, and it’s deliberate.

A single shared UDR (User‑Defined Route) per VNet or app tier is not just sub‑optimal, it is dangerous under assume‑breach conditions.

Here’s what actually happens during an incident:

A single subnet is suspected of compromise.
Containment requires changing egress or east‑west routing.
The route table is shared.
Isolation becomes a multi‑subnet blast event.
Legitimate workloads break.
On‑call engineers hesitate.
The attacker benefits from defender uncertainty.

At that moment, routing is no longer a connectivity concern.
It is a blast‑radius control plane and you’ve centralised it.

If isolating one subnet requires asking “what else uses this route table?”, the network does not fail safely.

Fail‑Safe Means “Small, Reversible Mistakes”

Under pressure, defenders will make imperfect calls.
Fail‑safe networks are designed around that reality.

Good failure looks like:

One subnet isolated, not a whole tier
One workload degraded, not all egress
Defender access preserved
Telemetry still flowing
Clear rollback paths

Bad failure looks like:

Widespread outages caused by containment
Automation immediately undoing emergency changes
Engineers afraid to touch the network mid‑incident

Assume breach is not about perfect response. It’s about survivable response.

Implementation Examples

This is about shape, not templates.

Subnet‑Scoped Isolation via NSGs

One practical pattern is designing isolation to be subnet‑local, without touching shared routing or central firewalls.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


resource isolationNsg 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
 name: 'nsg-isolation-app1'
 location: resourceGroup().location
 properties: {
 securityRules: [
 {
 name: 'Deny-All-Inbound'
 properties: {
 priority: 100
 direction: 'Inbound'
 access: 'Deny'
 protocol: '*'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: '*'
 sourcePortRange: '*'
 destinationPortRange: '*'
 }
 }
 {
 name: 'Allow-Defender-Access'
 properties: {
 priority: 110
 direction: 'Inbound'
 access: 'Allow'
 protocol: 'Tcp'
 sourceAddressPrefix: 'AzureBastion'
 destinationPortRange: '22'
 }
 }
 ]
 }
}

Boundary of this approach:
NSGs don’t override routing, and they don’t magically preserve return paths. They work because routing blast radius has already been constrained elsewhere. If your isolation depends on a shared UDR, this pattern collapses.

Architectural Shape: Containment Without Global Impact

flowchart LR subgraph VNet subgraph ZoneA["App Zone A"] A1[App Subnet] end subgraph ZoneB["App Zone B"] B1[App Subnet] end subgraph Control["Defender Control Plane"] Bastion Logs end end A1 -->|Explicit, Limited Paths| B1 A1 -->|Telemetry Only| Logs Bastion --> A1

The important property here is not segmentation it’s decision locality.

Containment decisions apply where the problem exists, not everywhere trust happens to be shared.

Gotchas & Edge Cases

Automation can be an attacker’s ally
Policy and IaC pipelines that auto‑remediate “drift” will happily undo containment unless explicitly designed not to. This is not a tooling bug, it’s a design failure.
Service and private endpoints can surprise you
Under containment, DNS resolution and endpoint reachability may not follow your mental model of “blocked traffic”. Treat them as reachability shortcuts that need explicit consideration.
Platform traffic still matters
Over‑zealous denies can break health probes, backups, or agent connectivity. Fail‑safe design preserves defender visibility first.

Best Practices

Treat routing as a blast‑radius control, not a convenience layer.
Avoid shared UDRs where containment scope matters.
Design isolation actions that are subnet‑local and reversible.
Preserve defender access and telemetry under all containment states.
Assume automation will act and decide whether it should during incidents.

🍺

Brewed Insight: I’ve made the shared‑UDR decision myself, more than once because it looked clean and “enterprise‑ready”.
Working through assume breach has forced me to re‑learn that convenience today often becomes fragility tomorrow, and that’s now something I actively push back on in my own designs.

Learn More

Mapping Attacker Movement Through Azure Networks

Thu, 16 Apr 2026 00:00:00 +1100

Most Azure networks aren’t breached because they’re badly built.
They’re breached because they’re too well connected.

Hub‑and‑spoke. Shared services. Clean routing. Minimal friction.
All sensible, until someone is already inside.

At that point, your network diagram stops being documentation and starts being a movement map.

Assume breach isn’t about stopping entry.
It’s about deciding how far someone can walk once they’re through the door.

The Mental Model

Common assumption:

“If it’s internal and peered, it’s trusted enough.”

This usually manifests as:

Broad hub‑to‑spoke peering
Shared services VNets reachable from everywhere
Routing optimised for convenience, not containment

Why it misleads:
Azure networking is not transitive in protocol terms but it is effectively transitive in operational reality.

If Azure’s control plane gives you a valid route:

The destination exists
The return path exists
The trust decision has already been made

NSGs may block traffic, but routing defines possibility.
And possibility is all an attacker needs to plan movement.

How It Really Works

Attackers don’t need clever tricks to move through Azure networks.
They rely on the same primitives your workloads do.

Routing Defines the Playing Field

System routes and peering expose:

Which address spaces are reachable
Which segments are adjacent
Which services sit “between” environments

Once a route exists, that relationship is discoverable, regardless of whether traffic is later denied.

Peering Is a Trust Boundary (Whether You Admit It or Not)

VNet peering establishes:

Mutual reachability
Automatic return paths
Address‑space visibility

From an assume‑breach lens, peering answers the most important question an attacker asks:

“What am I implicitly trusted to talk to?”

Shared Services Quietly Become Pivots

Jump hosts, automation, internal APIs, update services these aren’t neutral.
They are high‑leverage infrastructure.

When they’re broadly reachable, they stop being helpers and start being accelerators.

Real‑World Impact

This reframes how you should design and operate Azure networks.

Design: From Connectivity to Containment

The key question is no longer:

“Who needs access to this?”

It becomes:

“If this subnet is compromised, what trust does it inherit?”

That shift usually leads to:

Smaller, purpose‑bound VNets
Fewer unconditional peerings
Explicit containment boundaries that exist before an incident

Incident Response: Optionality Matters

During an incident you can’t redesign the network.
You can only remove paths.

Architectures that collapse operations and containment into the same peering force bad choices:

Keep dangerous paths open to preserve access
Or cut everything and accept collateral damage

Assume breach is about preserving choice under pressure.

Implementation Examples

The Diagram That Actually Matters

Most diagrams show connectivity.
This one highlights the single link that usually breaks containment.

Judgement, not illustration:

If a single peering link enables both normal operations and lateral movement during compromise, it is the wrong trust boundary.

In most environments, that link is: Spoke → Shared Services (often via the hub).

That is the path you will want to cut first and often can’t.

Inspecting the Paths You’ve Already Allowed

You don’t need attacker tooling to see this. Azure exposes it.

1
2
3


az network nic show-effective-route-table \
 --resource-group rg-app1 \
 --name nic-app1-vm01

When you review effective routes, ask one question:

If this destination were compromised, could I afford to isolate it immediately?

If the answer is no, that’s not connectivity, it’s embedded trust.

Shared Services: Unacceptable vs Merely Risky

This is where most architectures quietly fail assume breach.

Shared Services Are Unacceptable When

All of the following are true:

Broadly reachable from multiple spokes
Required during incidents (access, recovery, automation)
Difficult to isolate without breaking everything else

In this state, compromise of any spoke plausibly exposes:

The tools you use to respond
The systems you rely on to recover

That’s not risk it’s self‑defeating design.

Shared Services Are Merely Risky When

Risk is a conscious trade when:

The service is not required for containment
Trust is one‑way and disposable
Losing it degrades visibility, not control

Examples that often fall here:

Log ingestion
Metrics collection
Read‑only artifact distribution

The distinction isn’t shared vs not shared.
It’s optional vs non‑optional under duress.

Gotchas & Edge Cases

Firewalls and NVAs
Centralising enforcement doesn’t remove trust it concentrates it. Treat them as blast‑radius multipliers.
Private Endpoints
They add paths. They do not remove the need to reason about trust boundaries.
Overlapping address spaces
They delay containment decisions when time matters most.

Best Practices

Treat hub‑and‑spoke as a routing pattern, not a trust model
Classify services by incident criticality, not convenience
Minimise peerings you cannot sever quickly
Regularly review effective routes with a containment mindset
Document which links you would cut first before you need to

🍺

Brewed Insight:

Hub‑and‑spoke isn’t the problem.
Assuming the hub and what lives behind it, is always trusted is.

Design networks so you can afford to be wrong.

Learn More

Designing for Containment Over Prevention

Tue, 14 Apr 2026 00:00:00 +1100

Most Azure networks are designed like a pub with a strict door policy:
check IDs, keep trouble out, assume everyone inside behaves.

It works right up until it doesn’t and when it fails, the network usually has nothing useful left to say.

Assume‑breach changes the job of networking entirely.
Your network isn’t there to stop the first compromise. It’s there to stop the second, third, and fourth.

The Mental Model

The common assumption

If we get prevention right with private endpoints, no public IPs, hardened ingress then lateral movement becomes unlikely.

Why it breaks

Once an attacker gains a foothold anywhere inside the VNet, most Azure networks quietly revert to trust‑by‑proximity:

Large, shared address spaces
East‑west traffic implicitly allowed
Shared “infrastructure” services reachable from everywhere
Few boundaries that can be tightened quickly

At that point, prevention has already failed.
Containment is what decides whether the blast radius stays small or becomes organisational.

How It Really Works

Azure networking enforces reachability, not intent.

If a packet is routable and allowed by rules, Azure will move it consistently, quickly, and without judgement. There is no native concept of:

“This workload is untrusted”
“This subnet is compromised”
“This path should only exist during normal operations”

Containment emerges only when you design friction into the graph:

Boundaries that limit who can talk to whom
Paths that are explicit, narrow, and easy to revoke
Shared services that don’t silently collapse isolation

Think less about moats.
Think about fire doors that actually close.

Containment as a Measurable Outcome

If containment matters, it has to be testable without an incident.

Here’s a blunt, design‑time metric:

From any compromised workload, how many distinct network trust boundaries can it reach without a change request?

Not “in theory”.
Not “with enough effort”.
Right now, as deployed.

If the answer is most subnets in the VNet → containment is weak
If the answer is only its own role and one or two justified dependencies → containment exists
If answering requires trawling NSGs, routes, and diagrams → containment is unknowable (also a failure)

This isn’t a SOC metric.
It’s an architectural smell test.

Real‑World Impact

Designing for containment changes what “good” looks like.

Blast radius becomes explicit

A compromised workload should expose:

One role
One isolation unit
One small set of outbound paths

If compromise meaningfully increases reachability, your network is amplifying the incident.

Time becomes a defensive control

Every boundary:

Slows reconnaissance
Forces noisier behaviour
Buys response time without relying on alerts

Containment isn’t binary, it’s cumulative friction.

Defenders regain leverage

Good containment designs provide fast levers:

Subnets you can isolate without redeploying
Routes you can blackhole surgically
Rules you can tighten without breaking unrelated systems

If isolation requires redesign, it won’t happen under pressure.

Implementation Examples

Segmentation designed for incidents, not diagrams

This isn’t about tier purity.
It’s about what happens after AppA is compromised.

flowchart LR Internet -->|Inbound| Edge Edge --> AppA Edge --> AppB AppA --> DataA AppB --> DataB AppA -. blocked .-> AppB AppB -. blocked .-> AppA style AppA fill:#e3f2fd style AppB fill:#e8f5e9

In this design:

AppA compromise does not grant visibility or reachability into AppB
Isolation of AppA:
- Touches one subnet or NSG
- Does not affect AppB traffic paths
Defender action is local, not global

The topology isn’t clever.
The failure mode is.

NSGs as containment brakes, not hygiene

An NSG excerpt enforcing explicit east‑west denial:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


resource nsg 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
 name: 'appA-nsg'
 location: resourceGroup().location
 properties: {
 securityRules: [
 {
 name: 'Allow-Edge-In'
 properties: {
 priority: 100
 direction: 'Inbound'
 access: 'Allow'
 protocol: 'Tcp'
 sourceAddressPrefix: '10.10.0.0/24' // Edge subnet
 destinationPortRange: '443'
 }
 }
 {
 name: 'Deny-VNet-In'
 properties: {
 priority: 4096
 direction: 'Inbound'
 access: 'Deny'
 protocol: '*'
 sourceAddressPrefix: 'VirtualNetwork'
 destinationPortRange: '*'
 }
 }
 ]
 }
}

This rule doesn’t assume workloads behave.
It assumes one of them eventually won’t.

Shared Services: Where Containment Quietly Dies

Most containment failures aren’t caused by app tiers they’re caused by shared infrastructure.

DNS is the usual culprit.

A single, shared DNS resolver reachable from every subnet becomes:

A universal discovery service
An implicit trust bridge
Often, a stepping stone toward management planes or legacy systems

During incidents, DNS is rarely locked down first.
Which means once a workload is compromised, name resolution collapses isolation even if IP‑level rules look sound.

If every subnet can talk to the same DNS endpoint:

You don’t have independent containment zones
You have one network with polite boundaries

Containment requires shared services to be deliberately constrained, not just centrally managed.

Gotchas & Edge Cases

Service tags hide scope creep
VirtualNetwork expands as you add subnets. Containment erodes quietly.
Operational convenience pressures boundaries
If every exception weakens isolation, the design is already too brittle.
Management paths matter
Backup agents, patching, diagnostics, these are often the first lateral paths attackers exploit.

Best Practices (Containment‑Biased)

Design subnets as discrete isolation units, not convenience buckets
Prefer explicit allow paths over clever deny logic
Make isolation actions fast, local, and reversible
Treat route tables as incident controls, not static plumbing
Regularly answer the containment question not once, but continuously

🍺

Brewed Insight: If your network only works when everything behaves, it’s not defensive, it’s optimistic.
Containment is what turns inevitable failure into survivable failure.

Learn More

Network Isolation During Active Compromise: Designing for the Worst Day

Thu, 09 Apr 2026 00:00:00 +1100

Finding an attacker in your environment isn’t like spotting someone rattling the front door.
It’s like hearing footsteps upstairs.

At that point, the question isn’t how did they get in?
It’s how far can they go next and how fast can you stop that from getting worse?

In an assume‑breach model, network isolation is not an emergency manoeuvre.
It’s a downgrade path the network already understands.

The Mental Model

The common assumption

“If something gets compromised, we’ll isolate it.”

Isolation is treated as an action something responders do.

Why it breaks

During an active compromise:

You don’t know what’s already hostile
You don’t have time to redesign trust
You can’t safely assume the control plane is clean

If isolation requires:

New VNets
New peerings
Rule surgery across shared infrastructure

…then you don’t have isolation.

You have hope.

How It Really Works

Isolation that works under pressure is a structural property, not a procedural one.

The network must already encode:

Where trust is allowed
Where trust is explicitly not allowed
How a workload can be downgraded into a less‑trusted state

This is not about perfect segmentation.
It’s about pre‑authorised damage containment.

The key shift:
Isolation is not “blocking traffic”.
Isolation is forcing a workload into a smaller, poorer, deliberately constrained network world.

Real‑World Impact

Design

You stop grouping networks by:

Application name
Team ownership
Environment labels

And start grouping them by:

Blast radius tolerance
Containment requirements
What you are willing to lose without collapsing everything else

This almost always means:

Fewer fully‑meshed networks
More intentional asymmetry
Shared services treated as amplification risks, not conveniences

Reliability

Isolation‑capable designs fail unevenly, not catastrophically.

You trade some steady‑state elegance for:

Predictable degradation
Fewer “everything is on fire” incidents
Clear containment boundaries under stress

Availability becomes graduated, not binary.

Security

Once credentials or a workload are compromised:

East‑west movement is constrained by structure, not rules
Shared services don’t become free pivot points
Containment actions are coarse, fast, and reversible

Cost

Yes, this often costs more:

More VNets
More thought
More architectural discipline

It costs far less than rebuilding trust after full lateral spread.

Implementation Examples

This is not about NSGs, firewalls, or playbooks.
This is about what the network makes possible and impossible by design.

Designed isolation as a downgrade path

flowchart LR subgraph Prod VNet A[App Tier] B[Data Tier] end subgraph Shared Services VNet C[Identity & Control] D[Observability] end subgraph Isolation VNet E[Quarantine] end %% Normal operations A --> B A --> C B --> C A --> D B --> D %% Containment downgrade A -. isolate .-> E B -. isolate .-> E %% Explicitly impossible paths E -.-x C E -.-x B

What this diagram deliberately shows:

Isolation is a downgrade, not an alternative steady state
Workloads can move into quarantine, not back into shared trust
Quarantine has no path to identity or control services
Some connections are structurally absent, not “normally blocked”

If your design cannot express these absences, isolation will be fragile.

Structural artefact: isolation that exists before you need it

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


resource isolationVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
 name: 'vnet-isolation'
 location: resourceGroup().location
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.240.0.0/16'
 ]
 }
 }
}

resource prodVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
 name: 'vnet-prod'
 location: resourceGroup().location
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.10.0.0/16'
 ]
 }
 }
}

resource prodToIsolationPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
 name: '${prodVnet.name}/prod-to-isolation'
 properties: {
 remoteVirtualNetwork: {
 id: isolationVnet.id
 }
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: false
 allowGatewayTransit: false
 }
}

What matters here is not configuration detail, but intent:

The isolation VNet exists independently of any incident
A downgrade path is pre‑authorised
There is no equivalent peering to shared services
Containment does not require new infrastructure

If isolation requires new peerings, you are already too late.

Designed Isolation vs Wishful Containment

This distinction is non‑negotiable.

Designed isolation

Downgrade paths exist ahead of time
Shared services are not universally reachable
Containment changes routing, not architecture
Isolation is fast, coarse, and survivable

Wishful containment

Flat or fully‑meshed VNets
Shared services reachable from everywhere
Isolation requires redesign or mass rule changes
“We’ll block it when it happens”

Only one of these survives an active compromise.

Gotchas & Edge Cases

Shared services are blast‑radius multipliers
If everything depends on them, nothing can be isolated safely.
Fully‑meshed peering kills partial containment
You either isolate everything or nothing.
Late isolation is usually ineffective
Lateral movement is measured in minutes, not hours.
Over‑isolation can blind responders
If quarantine breaks logging or telemetry, you lose visibility when it matters most.

Best Practices

Treat isolation as a network state, not an action
Design explicit downgrade paths and only a few
Group networks by failure tolerance, not org charts
Assume shared services are hostile by default
If isolation requires design changes, it doesn’t exist

🍺

Brewed Insight: If your network can’t force a compromised workload into a smaller, poorer world without redesign, you didn’t design for isolation, you designed for optimism.

Learn More

Defining Blast Radius in Azure Networks

Tue, 07 Apr 2026 00:00:00 +1100

Most Azure networks aren’t designed to fail gracefully.

They’re designed to be convenient: easy peering, wide address space, few hard edges. Everything works, deployments are fast, nobody blocks progress.

Until something breaks in the worst possible way, a compromised workload already inside the network and you discover that “convenient” and “contained” are rarely the same thing.

In an assume‑breach model, blast radius isn’t theoretical. It’s the difference between an incident and an outage‑shaped investigation.

The Mental Model

The common assumption

VNets are boundaries. If we didn’t mean for things to talk, security controls will handle it.

This model treats:

Address space as neutral
Peering as low‑risk plumbing
Routing as an implementation detail

Security, in this framing, lives elsewhere.

Why it breaks

Azure networking is opinionated in one quiet but important way:

If traffic is routable, the platform assumes it’s legitimate.

VNets, peerings, and routes don’t express intent. They express possibility. Once a packet has a valid path, Azure does not ask whether that path aligns with your threat model.

In an incident, possibility always beats intent.

How It Really Works

Blast radius in Azure networks is shaped by structural reachability, not by how carefully your firewall rules are written.

Three mechanics matter most.

Address space sets the outer limit

CIDR ranges define what could ever be reached.

If two workloads sit in address spaces that can be routed between:

They are part of the same potential blast radius
Any containment relies on controls outside the network layer

Addressing is not bookkeeping. It’s scope definition.

Peering collapses assumed boundaries

VNet peering creates:

Full IP reachability between address spaces
No inherent notion of trust direction
No concept of “only for these workloads”

From a routing perspective, peered VNets behave like a single, larger network unless you deliberately constrain paths.

That’s efficient. It’s also expansive.

Routing decides how compromise spreads

User Defined Routes (UDRs), system routes, and propagated paths answer one question during an incident:

Where can packets actually go right now?

The answer is often broader and less remembered than architects expect.

Real‑World Impact

Under assume breach, blast radius isn’t an abstract risk. It shows up as very concrete outcomes:

A Non‑Prod compromise that suddenly has line‑of‑sight to Prod
A “small” spoke that can reach far more than its owners realise
An incident response slowed down by surprise connectivity

The pattern is consistent: networks optimised for convenience quietly optimise for spread.

Blast Radius Smell Tests

These aren’t best practices. They’re gut checks you can run against a real estate as it exists today.

1. Reachability Without Intent

Question to ask:
Can this workload reach IP ranges it was never explicitly designed to talk to simply because routing allows it?

If the answer is yes, that reachability is part of your blast radius, regardless of firewall posture.

This smell commonly comes from:

“Just in case” peering
Broad, loosely allocated address space
Default routes no one has reviewed in years

Under breach conditions, attackers care about what’s reachable, not what was intended.

2. Environment Boundaries That Only Exist in Diagrams

Question to ask:
If I ignore names, subscriptions, and tags, are Prod and Non‑Prod actually isolated at the routing layer?

If environments are routable:

They are not isolated
They simply rely on convention to stay apart

Attackers don’t see environments. They see IP ranges and next hops.

If a Non‑Prod workload is compromised, the network decides whether that incident stays there, not your naming standards.

3. Temporary Connectivity That Never Left

Question to ask:
Which peerings or routes would surprise you if they appeared in an incident review?

Migration links, troubleshooting routes, one‑off access that “we’ll remove later” these quietly accumulate.

They are dangerous because:

They’re forgotten
They’re rarely monitored
They aren’t defended in anyone’s mental model

Routing doesn’t care how old a decision is.

Implementation Examples

Visualising accidental blast radius

graph TD Shared["Shared Services VNet
10.0.0.0/16"] Prod["Prod VNet
10.1.0.0/16"] NonProd["Non‑Prod VNet
10.2.0.0/16"] Shared --- Prod Shared --- NonProd

This looks segmented.

From a routing perspective, it often isn’t. Shared services become an implicit bridge unless paths are deliberately constrained.

A peering that widens scope by default

1
2
3
4
5
6
7
8


resource nonProdToShared 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-11-01' = {
 name: 'nonprod-to-shared'
 parent: nonProdVnet
 properties: {
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: true
 }
}

Nothing here is misconfigured.

But combined with similar peerings elsewhere, this enables:

Lateral reach that wasn’t consciously designed
Incident paths that rely entirely on downstream controls to stop spread

That’s blast radius expressed as configuration.

Gotchas & Edge Cases

Subscription boundaries don’t limit routing
Address space reuse hides, rather than reduces, blast radius
Old peerings are rarely re‑evaluated
Default system routes often enable more reach than diagrams suggest

If you haven’t inspected effective routes during a failure scenario, you don’t actually know your containment story.

Best Practices

Treat every routable path as an explicit trust decision
Align address space with containment goals, not just growth
Periodically review reachable IP ranges, not just VNets
Remove connectivity that no one can clearly justify today

This is architectural discipline, not extra tooling.

🍺

Brewed Insight: Blast radius is rarely expanded by bold decisions.
It’s expanded by quiet ones no one revisits.

Learn More

Easter Weekend AI Project

Sat, 04 Apr 2026 00:00:00 +1100

An Easter Weekend Experiment with Copilot CLI

Over the Easter weekend I decided to get my hands dirty with something a little different. No production workloads, no architectural diagrams, no pressure. Just a small, contained experiment to see what GitHub Copilot CLI actually feels like when you let it roam a bit.

The target was my personal resume site. It already existed and technically did the job, but if I’m being honest it was being held together with good intentions and duct tape. Functional, but inconsistent, messy, and very clearly something I’d been meaning to clean up “one day”.

This felt like the right kind of project to experiment on.

The Mission (Intentionally Vague)

The brief I gave Copilot CLI was deliberately loose: modernise it.
No wireframes. No detailed spec. No careful breakdown of tasks. I just pointed it at the repo and let it ask questions.

That looseness was intentional. I wasn’t trying to see how well it followed instructions, but how it behaved when it had room to propose rather than just execute.

From Idea to Running Locally

After a bit of back‑and‑forth and a couple of nudges from me on concepts I cared about, Copilot CLI put together a plan, created a new branch, scaffolded the changes, handled npm, and got a local version running.

End to end, including me stopping to take notes for this post, the whole thing took around 30 minutes.

That’s not nothing.

What Actually Changed

Cosmetically, the result isn’t a dramatic departure. If you didn’t know to look, you might not even notice much difference at first glance.

Under the hood though, it’s a different story. The code is cleaner, better structured, and actually commented throughout in a way the original never was. The site feels like something I’d be comfortable picking up again in six months without immediately regretting past‑me’s decisions.

There were also a few small additions that came from giving the AI a bit of creative freedom. A simple theme switcher, for example. Slightly weird, not strictly necessary, and probably something I wouldn’t have bothered implementing manually—but I was happy to have it along for the ride.

I’m not a UX designer, and I didn’t pretend to be. But letting Copilot suggest alternate approaches to layout and UX, rather than just fixing exactly what I pointed at, genuinely lifted the site in ways I wouldn’t have thought to ask for.

Why This Was Interesting

The most useful part of the exercise wasn’t speed, and it wasn’t raw code generation.

It was what happened when I stopped treating the tool like a very fast typist and instead let it propose options. Plans. Alternatives. Things to react to rather than instructions to follow.

That shift—from “do this” to “show me what you’d do”—was where the value showed up.

A Thought Before You Try Something Similar

This kind of experiment works precisely because the stakes are low. I wouldn’t point Copilot CLI at a regulated production system and say “modernise it” with a straight face.

But if your AI usage still looks like autocomplete, boilerplate, or shaving a few minutes off typing, you’re probably missing the more interesting part.

If you’re going to play with these tools, do it somewhere safe—and do it in a way that forces you to exercise judgment, not just measure speed.

That’s where things actually start to get interesting.

Learn More

Assume Breach: Why Flat VNets and Permissive NSGs Fail When It Matters

Thu, 02 Apr 2026 00:00:00 +1100

Most Azure environments aren’t breached because the firewall was missing.

They’re breached because once something failed, nothing slowed the attacker down.

Flat VNets and permissive NSGs feel productive. They reduce friction. They keep deployments moving.
But under an assume‑breach model, they don’t just fail to help — they actively make things worse.

This post reframes assume breach as a network design principle, then calls out two design choices that are incompatible with it.

The Mental Model

The common assumption

If everything is “internal”, broad connectivity is fine.

We can always tighten it later.
NSGs document intent.
Segmentation is something we add when security asks for it.

Why it breaks in the cloud

In Azure, compromise doesn’t arrive politely at the edge.

It arrives through:

leaked credentials
over‑permissioned workloads
compromised build agents
exposed management endpoints
misconfigured services

Once any internal workload is hostile, the question isn’t can it get in?
It’s how far can it go before anyone notices?

Flat networks and permissive rules answer that question very badly.

How It Really Works

Assume breach treats networking as a containment mechanism, not a convenience layer.

When a workload is compromised, the network should:

restrict what it can see
restrict what it can reach
restrict how quietly it can move

If the network does none of those things, it’s not neutral — it’s an accelerator.

Two common Azure patterns fail this test consistently.

Design Flaw #1: Flat VNets Justified by “It’s All Internal”

What this looks like

One large VNet
Multiple subnets by tier or function
NSGs with wide VirtualNetwork allows
East‑west traffic largely unrestricted

This is often defended as:

simpler
easier to operate
faster to deploy

Why it’s actively dangerous

Under assume breach, a flat VNet pre‑authorises lateral movement.

Once an attacker compromises:

a single VM
an app service with VNet integration
a container with network access

They inherit:

cheap reconnaissance
broad reachability
low‑noise scanning opportunities

The network doesn’t slow them down.
It helps them map your environment faster than you can respond.

This isn’t a theoretical risk. It’s how most real cloud incidents expand.

Design Flaw #2: NSGs Used as Documentation Instead of Enforcement

What this looks like

Large rule sets with “temporary” allows
Broad source prefixes “for flexibility”
Deny rules that technically exist but rarely trigger
Rules written to avoid breaking anything — ever

NSGs become a record of intent, not a constraint.

Why it’s actively dangerous

In a breach, ambiguity favours the attacker.

Permissive rules mean:

unclear blast radius
unpredictable access paths
difficulty reasoning under pressure

When incident response begins, teams often discover:

rules no one remembers adding
dependencies no one documented
access paths no one intended

At that point, tightening the network risks breaking production — so it doesn’t happen.

The attacker keeps moving.

Real‑World Impact

Design

You stop grouping resources by convenience and start grouping by what you’re willing to lose together.

If a subnet is compromised, what must still be unreachable?

Reliability

Containment prevents security incidents from becoming availability incidents.

A compromised workload shouldn’t be able to:

reach other workloads of the same tier
traverse management paths
interfere with recovery mechanisms

Security

Security posture improves after failure, not just before it.

That’s the difference between:

a design that looks secure on a diagram
a design that survives partial compromise

Cost

More segmentation costs something.

Unbounded lateral movement costs far more — usually measured in downtime, incident duration, and lost confidence rather than Azure spend.

Implementation Examples

Assume breach doesn’t require complex tooling.
It requires default denial and explicit intent.

Example: NSG as enforcement, not commentary

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


param location string = resourceGroup().location
param workloadsubnetresourcegroup string = 'rg-aue-networking'
param workloadvnetname string = 'vnet-workload'
param workloadsubnetname string = 'subnet-workload'
param nsgName string = 'nsg-workload'

resource workloadSubnet 'Microsoft.Network/virtualNetworks/subnets@2023-09-01' existing = {
 scope: resourceGroup(workloadsubnetresourcegroup)
 name: '${workloadvnetname}/${workloadsubnetname}'
 }

resource workloadSubnetNsg 'Microsoft.Network/networkSecurityGroups@2023-09-01' = {
 name: nsgName
 location: location
 properties: {
 securityRules: [
 {
 name: 'Allow-Explicit-Dependency'
 properties: {
 priority: 100
 direction: 'Outbound'
 access: 'Allow'
 protocol: 'Tcp'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: workloadSubnet.properties.addressPrefix // dependency subnet
 destinationPortRange: '443'
 }
 }
 {
 name: 'Deny-East-West-Default'
 properties: {
 priority: 4096
 direction: 'Outbound'
 access: 'Deny'
 protocol: '*'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: 'VirtualNetwork'
 destinationPortRange: '*'
 }
 }
 ]
 }
}

This doesn’t stop compromise.
It defines how far compromise can travel.

That’s the point.

Visualising the Difference

Flat, trust‑by‑default design

flowchart LR CompromisedWorkload --> SubnetA SubnetA --> SubnetB SubnetB --> SubnetC SubnetC --> Data

Movement is easy, fast, and quiet.

Assume‑breach‑oriented design

flowchart LR CompromisedWorkload --> SubnetA SubnetA -.blocked.- SubnetB SubnetA --> ExplicitDependency

The attacker hits friction immediately.

Gotchas & Edge Cases

Over‑segmentation can hurt operability
If engineers can’t diagnose issues during an incident, the design has overshot.
Platform traffic still needs consideration
Health probes, control plane access, and managed service behaviour must be explicitly allowed — not assumed.
NSGs are not policy engines
Keep rules few, intentional, and aggressively pruned.

Best Practices

Treat “internal” as a routing concept, not a trust guarantee
Design subnets around failure domains, not org charts
Default to east‑west deny, then add explicit intent
Regularly delete rules you can’t justify under breach
Revisit network boundaries after incidents — not just audits

🍺

Brewed Insight:

Flat networks and permissive NSGs don’t just fail under breach — they make compromise faster, quieter, and harder to contain.

If your network can’t limit damage after something goes wrong, it’s not defensive architecture. It’s optimism.

Learn More

Global Secure Access MVP: Secure and Private Without Pretending It’s a Network

Tue, 31 Mar 2026 00:00:00 +1100

Global Secure Access (GSA) is easy to misunderstand because it looks like a network product.

There’s a client. There are connectors. Traffic flows somewhere else. The instinct is to treat it like a VPN refresh and design the end state up front. That instinct is also how teams end up with oversized blast radii and no clean rollback.

This post takes a different position: a successful GSA rollout behaves more like introducing a new control plane than replacing old plumbing. The goal here is not completeness. It’s observability, reversibility, and learning fast.

The Mental Model

The common assumption:
You must model all access paths before enabling Global Secure Access.

Why it misleads:
GSA is policy‑driven software that happens to move packets. Its failure modes are not link failures or route leaks they’re policy mismatches, connector health issues, and identity gaps.

A minimum viable implementation (MVP) should therefore:

Limit who is affected
Limit what traffic is touched
Expose operational behaviour early

If your first deployment can’t be safely undone in minutes, it’s too big.

How It Really Works (MVP View)

At runtime, the GSA client classifies traffic locally and forwards selected flows to Microsoft’s Security Service Edge (SSE). Decisions are enforced using Conditional Access signals before traffic reaches Microsoft 365, the internet, or a private app.

Private Access extends this model by introducing connectors that only ever make outbound connections. No inbound exposure, no implicit network reachability.

This is not network extension. It’s identity‑mediated brokering.

MVP Traffic Flow Overview

This diagram is intentionally boring. That’s the point. Complexity lives in policy, not topology.

MVP Scope and Explicit Non‑Goals

In scope

Microsoft 365 traffic
Limited internet access
One private application
Windows devices only

Explicitly out of scope

Full VPN replacement
Broad internet inspection
Application portfolios
Non‑HTTP legacy protocols

Deferring these is not a limitation. It’s an architectural choice.

Step 1 – Enable Global Secure Access

In the Microsoft Entra admin centre:

Navigate to Global Secure Access → Settings
Enable Global Secure Access

Nothing routes yet. This is a control‑plane activation, not a traffic change.

Step 2 – Define a Constrained Pilot

Create a security group:

GSA-MVP-Pilot

This group is your blast radius. If you can’t clearly articulate why someone belongs here, they don’t.

Step 3 – Enable Secure Access Traffic Profiles

Under Traffic forwarding:

Enable Microsoft 365
Enable Internet Access
Leave advanced inspection features disabled

At this stage, enabling profiles without clients deployed changes nothing a useful property when rolling out safely.

Step 4 – Deploy the GSA Client (Windows)

Deploy the Global Secure Access client via Microsoft Intune and assign it to GSA-MVP-Pilot.

This step matters less for how it’s done and more for what it enables: device‑level traffic classification that participates in Conditional Access decisions.

If the client doesn’t connect reliably, stop. Everything else depends on this.

Step 5 – Validate Secure Access First

Before touching Private Access:

Confirm Microsoft 365 works as expected
Confirm internet access behaves normally
Inspect Global Secure Access traffic logs

You’re validating signal quality, not just connectivity.

If Secure Access isn’t observable and predictable, Private Access will amplify the confusion.

Step 6 – Deploy Private Network Connectors

Deploy at least two connectors per location:

Windows Server
Outbound HTTPS only
Close to the application, not the users

Connector health is now part of your application’s availability story. Treat it that way.

Step 7 – Publish a Single Private Application

In Private Access → Applications:

Define the application by FQDN and port
Avoid CIDR‑based definitions
Assign access to GSA-MVP-Pilot

Red flags for MVP inclusion:

Hard‑coded IP dependencies
Embedded DNS assumptions
Latency‑sensitive chatty protocols

Some apps are simply bad first candidates. Excluding them is a design decision, not a failure.

Step 8 – Enforce Conditional Access

Create a Conditional Access policy scoped to:

Users: GSA-MVP-Pilot
Cloud app: Global Secure Access

Require:

Compliant device
MFA

Without this, you’re proxying traffic not governing access.

Step 9 – Validate Private Access Behaviour

From a pilot device:

Access the private app via its FQDN
Confirm authentication flow
Monitor connector metrics and sign‑ins

Expect additional latency compared to on‑network access. The trade‑off is explicit control and visibility.

If that trade‑off is unacceptable for a given app, that’s valuable information early.

Gotchas That Actually Matter

Connector resource starvation looks like “random slowness”
DNS mismatches fail silently
Policy changes can have wider impact than expected
Break‑glass access paths must be planned, not improvised

These are operational problems, not configuration mistakes.

Best Practices for Moving Beyond MVP

Expand users slower than applications
Add connectors before you need them
Version and review policy changes
Monitor GSA like an application dependency

At scale, this is an access platform, not a feature.

🍺

Brewed Insight: Global Secure Access rewards teams that treat access as a living control system. If you approach it like static plumbing, it will behave like one until it doesn’t.

Learn More

Where Global Secure Access Fits in Enterprise Azure Architectures

Thu, 26 Mar 2026 00:00:00 +1100

Most enterprise Azure architectures still draw a clean picture: management groups, landing zones, hubs, spokes, firewalls and somewhere off to the side, user access.

Global Secure Access (GSA) refuses to stay in that box.

If you try to drop it into your hub as “the new VPN”, you’ll spend months fighting the platform and each other. This post is about placing GSA where it actually belongs in Azure‑centric enterprise architectures, and why getting that placement wrong causes more organisational pain than technical failure.

The Mental Model

Common assumption:
Global Secure Access is a networking service that should sit alongside Azure Firewall, VPN Gateway, or ExpressRoute.

Why that breaks:
GSA doesn’t participate in your virtual network topology. It doesn’t understand subnets, routes, or east‑west flows. It never becomes part of your Azure data plane.

The correct mental model is:

Global Secure Access lives in the identity and access plane not the network plane.

Once traffic passes GSA, Azure networking starts. Before that, it’s an identity problem.

How It Really Works

At a behavioural level, Global Secure Access:

Anchors user traffic to Microsoft’s edge
Evaluates identity, device posture, and context through Microsoft Entra
Forwards authorised traffic to Microsoft‑managed service endpoints

What it deliberately does not do:

Terminate inside your VNets
Participate in routing decisions
Enforce segmentation inside Azure
Replace firewalls, NSGs, or platform controls

From Azure’s point of view, GSA‑sourced traffic simply arrives pre‑authorised. Everything after that remains a platform responsibility.

Architectural Placement in Enterprise Azure

Above subscriptions, not inside them

Because GSA is Entra‑scoped:

It fronts all subscriptions and environments
It ignores management group boundaries
It doesn’t care about landing zone topology

That makes it a pre‑network control layer, not a shared service VNet.

This also explains why it scales cleanly across dev, test, and prod without duplicating access infrastructure.

Responsibility Boundaries (This Is Where Teams Trip)

Global Secure Access forces a line most enterprises haven’t clearly drawn:

Concern	GSA	Azure Platform
User identity	✅	❌
Device posture	✅	❌
Access decision	✅	❌
Blast radius control	❌	✅
Network segmentation	❌	✅
East‑west traffic	❌	✅

A hard‑earned lesson from the field:

GSA fails fastest in organisations that haven’t agreed who owns access decisions versus blast‑radius control.

If network teams try to “own” GSA, they’ll look for IPs and routes that don’t exist.
If identity teams ignore platform constraints, Conditional Access quietly becomes a segmentation substitute.

Neither ends well.

Preview Reality: Not a Tier‑0 Dependency

GSA is evolving quickly which makes it powerful, but also unsuitable as a tier‑0 dependency today.

Architectural implications:

Losing GSA must not lock you out of Azure administration or identity recovery
Critical break‑glass paths should not depend on GSA availability
Early adoption should focus on learning placement, not removing fallback access paths

This isn’t caution for caution’s sake it’s about respecting change velocity in identity‑driven services.

Where It Fits and Common Anti‑Patterns

Where it fits well

Azure‑hosted private applications with Entra integration
Microsoft 365 and SaaS consolidation
Identity‑first Zero Trust strategies
Enterprises reducing IP‑based allow‑listing

Anti‑patterns to avoid

Invisible network means no network responsibility
When user ingress becomes identity‑anchored, platform teams sometimes disengage entirely. The result is unclear failure domains and slower incident response.

GSA as a private endpoint replacement
Identity‑based access does not remove the need for network isolation. East‑west containment still matters.

One access layer to rule them all
Forcing GSA to front service‑to‑service or automation traffic creates brittle designs and breaks non‑interactive workloads.

Signals That Change (And What Replaces Them)

Introducing GSA quietly invalidates a set of assumptions many platform teams rely on.

Signals you should stop expecting

Source IP addresses as identity
Packet captures at the VNet edge for user traffic
Firewall rule hit counts as access evidence
Network logs answering “who accessed what”

Signals you need to replace them with

Entra sign‑in and audit logs as the primary access record
Application‑level telemetry for success and failure
Policy evaluation outcomes instead of rule matches
Clear escalation paths between identity, platform, and app teams

Put simply:

Access becomes an identity event first, and a network event second.

Your operational model needs to follow that order.

Conceptual Placement Diagram

flowchart LR User[User Device] --> GSA[Global Secure Access Edge] GSA --> Entra[Microsoft Entra ID] Entra -->|Authorised Access| AppEndpoint[Azure App Endpoint] AppEndpoint --> VNet[Landing Zone VNets] VNet --> Firewall[Azure Firewall / NSGs]

GSA gates entry.
Azure networking governs everything after.

Best Practices

Treat GSA as an identity capability, not a network service
Keep Azure network segmentation intact
Align GSA ownership with identity governance teams
Document responsibility boundaries explicitly
Avoid turning Conditional Access into a proxy for segmentation

🍺

Brewed Insight: Global Secure Access doesn’t simplify Azure networking it removes user ingress from it.
That only works if your organisation is ready to change how it thinks about access, visibility, and responsibility.

Learn More

Securing SaaS and Private Apps with Global Secure Access

Tue, 24 Mar 2026 00:00:00 +1100

For a long time, securing applications has followed a comfortable sequence:

Make the app reachable
Authenticate the user
Hope nothing changes mid‑session

Global Secure Access (GSA) challenges that order. It assumes that change is the default users roam, devices drift out of compliance, risk signals evolve and asks whether access should still exist right now.

That framing matters when you’re securing both SaaS and private applications, because it moves the problem away from network exposure and toward session‑level trust.

The Mental Model

Common assumption:
SaaS applications are secured with identity. Private applications are secured with networks.

Why it breaks:
Attackers don’t differentiate. They exploit authorised sessions, not architectural categories.

Global Secure Access treats SaaS and private apps the same way: as destinations that require an explicit, continuously justified decision to access. The control plane doesn’t care where the app lives only who is accessing it, from what, and under what conditions.

The real shift isn’t SaaS versus private.
It’s implicit reachability versus evaluated access.

How It Really Works

Global Secure Access inserts a user‑aware enforcement layer in front of application traffic.

In practice:

Users authenticate with Microsoft Entra ID.
Traffic is associated with an authenticated user session, not an IP address.
Conditional Access (CA) policies are evaluated based on identity, device state, and risk.
Access is granted or denied before traffic reaches the application.

An important boundary to be explicit about:

Global Secure Access evaluates access to the session, not authorisation inside the application.

If an application accepts a bearer token indefinitely, GSA won’t save you from that design choice. It can revoke or deny future access, but it cannot fix weak application‑level trust models.

That distinction is where a lot of confusion and overconfidence creeps in.

Real‑World Impact

SaaS applications

With GSA in place, SaaS access stops being a one‑time decision at sign‑in.

You gain:

Consistent Conditional Access enforcement across SaaS providers
Explicit session lifetime controls
The ability to react to changing risk signals

Operationally, this means:

A user’s access can be revoked without touching the app.
Unmanaged or risky devices don’t quietly retain access.
Location and corporate networks stop being trusted signals by default.

Private applications

For private apps, the impact is more structural.

Access no longer requires:

Broad network reachability
IP allow‑listing gymnastics
Assuming “on the network” equals “trusted”

Instead:

Users are authorised per application, not per subnet.
Reachability follows identity, not topology.
Lateral movement opportunities are significantly reduced.

This doesn’t modernise legacy applications but it does contain their blast radius far more effectively than network‑centric controls.

Implementation Examples

Conceptual access flow

The application never sees the request unless identity and session policy say it should.

Conditional Access policy (illustrative)

Below is a simplified Conditional Access policy targeting a private application accessed via Global Secure Access.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


{
 "displayName": "GSA - Private App - Require Compliant Device",
 "state": "enabled",
 "conditions": {
 "users": {
 "includeUsers": ["All"]
 },
 "applications": {
 "includeApplications": ["<private-app-enterprise-app-id>"]
 },
 "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
 },
 "grantControls": {
 "operator": "AND",
 "builtInControls": [
 "mfa",
 "compliantDevice"
 ]
 },
 "sessionControls": {
 "signInFrequency": {
 "value": 8,
 "type": "hours"
 }
 }
}

Why this matters in production:

Access can be withdrawn centrally without redeploying the app.
Device posture becomes a hard requirement, not guidance.
Session lifetime is an explicit decision, not an accident.

Gotchas & Edge Cases

Authorised misuse still exists
Global Secure Access is excellent at preventing unauthorised access. It is far less effective at containing authorised abuse.
Legacy token behaviour matters
Long‑lived or non‑expiring tokens undermine session‑based controls. Identity enforcement can only be as strong as the app’s trust model.
Policy confidence depends on signal quality
Device compliance and risk signals must be reliable. Weak inputs lead to confident but wrong decisions.
Feature maturity varies
Parts of Global Secure Access are still evolving. Always confirm GA status before relying on specific behaviours in production designs.

Best Practices

Treat SaaS and private apps identically in access policy language.
Be explicit about session lifetime this is a business decision, not a technical default.
Use device compliance as a baseline requirement, not a conditional add‑on.
Design access policies around user intent, not network location.
Document where GSA enforcement ends and application responsibility begins.

🍺

Brewed Insight:

Global Secure Access materially reduces attacks that rely on unauthorised reachability stolen credentials, unmanaged devices, and accidental exposure. It does very little to stop attacks that occur after legitimate access is granted.

In other words: GSA is very good at deciding who gets to knock on the door and mostly irrelevant once you’ve let the wrong person inside.

Learn More

Designing Hybrid User Access with Identity‑Driven Routing

Thu, 19 Mar 2026 00:00:00 +1100

Every time we talk about identity‑driven access, someone eventually says:

“So networking won’t need to worry about user access anymore, right?”

That question alone tells you where most hybrid designs go wrong.

Global Secure Access (GSA) doesn’t remove the network from user access.
It changes where decisions are made, not who carries the pager.

If you design hybrid user access assuming identity ownership replaces network ownership, you’re setting yourself up for confused outages and slower recovery not better security.

The Mental Model

The common assumption

“Identity‑based access replaces network‑based access.”

This frames identity and networking as competing models.

Why this breaks down

In real hybrid estates:

Packets still traverse networks you own and operate
Latency, path asymmetry, DNS, and MTU still matter
When users can’t connect, the networking team still gets called first

Identity doesn’t replace networking.
It moves the access decision upstream, before transport is exercised.

That distinction matters operationally.

How It Really Works

Identity is the control plane, not the data plane

With GSA, identity determines:

Who is allowed
Under what conditions
To which class of resource

What it does not do:

Eliminate routing complexity
Remove dependency on underlying connectivity
Magically simplify incident response

Once access is approved, traffic still flows via:

Microsoft’s global edge (for SaaS and some private access), or
Existing enterprise paths (VPNs, ExpressRoute, on‑prem routing)

The decision logic is centralised.
The transport remains distributed.

That separation is the architectural shift.

Real‑World Impact

How this changes what you design, deploy, and operate

Design

You stop designing networks around “trusted locations”
You start designing around decision boundaries:
- Identity boundary (who is allowed)
- Application boundary (what they’re accessing)
- Transport boundary (how traffic moves)

Operations

Incidents still land with networking — and that’s correct
Identity becomes a diagnostic input, not the owner of resolution
Faster isolation when teams share a common mental model

Reliability

Identity failures and transport failures decouple slightly, not fully
Clearer blast radius when access logic is centralised
Fewer cascading failures caused by duplicated controls

Conceptual Architecture: Hybrid, Not Replaced

flowchart LR User[User Device] IdP[Microsoft Entra ID] GSA[Global Secure Access Edge] SaaS[SaaS Applications] PrivateApp[Private Applications] CorpNet[Enterprise Network] OnPrem[On‑Prem Resources] User --> IdP IdP -->|Access Decision| GSA GSA --> SaaS GSA --> PrivateApp GSA --> CorpNet CorpNet --> OnPrem

Key point:
Identity determines whether traffic is allowed.
Networking determines whether it actually flows.

Decision Boundaries That Matter in Practice

SaaS vs Private Applications

This is where most organisations draw the first clean line.

SaaS
- Identity‑first access is natural
- Transport complexity is largely abstracted
- Networking impact is minimal and predictable
Private applications
- Identity gates access
- Networking still owns reachability, performance, and failure modes
- Coexistence with VPNs and fixed paths is normal — often long‑term

The mistake is assuming both categories behave the same operationally.

Transitional States Are the Architecture

Hybrid user access is not a phase — it’s a sustained state.

Common patterns that actually work:

Dual paths by design
- Identity‑driven access for modern apps
- Legacy paths retained for brittle workloads
Identity consistency first
- Centralise access decisions before touching transport
Application‑level intent
- Each app declares identity requirements independently of network paths

If your architecture diagram doesn’t show coexistence, it’s lying.

Operational Reality: Who Owns the Incident?

This is the uncomfortable part.

When a user can’t reach an internal app:

The ticket goes to networking
The networking team must diagnose:
- Identity decision outcome
- Edge routing behaviour
- Underlying path health

Identity‑driven routing does not remove networking ownership.
It raises the bar on what networking teams need to understand and observe.

The success metric isn’t fewer tickets.
It’s faster, more confident diagnosis.

That only happens when:

Networking teams understand identity‑driven access models
They have visibility into identity decisions
Identity and network tooling are treated as part of the same system

Why There’s No Implementation Section Here

This post intentionally avoids configuration snippets.

At this stage of design:

Implementation details create false confidence
Feature‑level controls distract from architectural intent
The real risk is misaligned ownership, not misconfigured policies

Concrete implementation belongs later, once the decision boundaries are agreed.

Gotchas & Edge Cases

Identity success ≠ connectivity success
Approval does not guarantee reachability.
Ambiguous routing during coexistence
Multiple valid paths confuse users and operators alike.
Team silos become incident amplifiers
If identity and networking operate independently, outages last longer.

Best Practices

Treat identity as a shared dependency, not a handoff
Design hybrid states explicitly — document them
Assume networking owns the outage, then design to help them
Invest in diagnostics before optimisation
Resist the urge to “finish” the migration too early

🍺

Brewed Insight: Identity‑driven routing doesn’t change who gets paged — it changes how quickly they understand the problem.
If your networking team isn’t fluent in the identity model, you haven’t simplified anything.

Learn More

Global Secure Access vs VPNs, Private Endpoints, and ExpressRoute

Tue, 17 Mar 2026 00:00:00 +1100

Every few years, user access gets “simplified”.

First it was VPN consolidation.
Then it was Private Endpoints everywhere.
Now it’s Global Secure Access (GSA).

The pitch changes, but the mistake stays the same: treating all user access technologies as if they compete in the same layer.

They don’t.

This post is about why GSA doesn’t replace VPNs, Private Endpoints, or ExpressRoute and why trying to make it do so usually weakens your architecture.

The Mental Model

The common assumption

“Global Secure Access is the modern answer to user connectivity. Over time, everything should move to it.”

Why this breaks

That assumption collapses trust, transport, and control into a single decision.

In reality:

VPNs trust reachability
Private Endpoints trust network placement
ExpressRoute trusts physical transport
Global Secure Access trusts identity context

Once you blur those boundaries, you stop designing access, you start accumulating risk.

How It Really Works

The cleanest way to compare these technologies isn’t features.
It’s where decisions are made and what must be trusted to make them.

Global Secure Access (GSA)

Control plane: Microsoft Entra ID (identity, device, session context)
Data plane: Microsoft‑managed global edge
Enforcement point: Per‑user, per‑session, per‑application

GSA makes a deliberate trade‑off:

You gain fine‑grained, identity‑driven access
You accept a hard dependency on the identity control plane

That trade‑off is powerful and non‑negotiable.

VPN (Client / Point‑to‑Site)

Control plane: Network authentication (certs, tokens, sometimes Entra ID)
Data plane: Encrypted tunnel into a network
Enforcement point: Subnets, routes, firewalls

VPNs don’t understand applications.
They grant presence, then rely on network controls to contain it.

This is a blunt tool but sometimes blunt is exactly what you want.

Private Endpoints

Control plane: Azure Resource Manager
Data plane: Private IP inside a VNet
Enforcement point: Network isolation

Private Endpoints don’t solve user access at all.
They solve service exposure.

They assume:

“Whatever reaches this VNet is already trusted enough.”

How that trust is established is someone else’s problem.

ExpressRoute

Control plane: Circuit provisioning and Azure configuration
Data plane: Private, predictable transport
Enforcement point: Network boundaries and upstream controls

ExpressRoute optimises how traffic moves, not who should be allowed.

Treating it as a Zero Trust mechanism is a category error and a common one.

Same user, four trust anchors

flowchart LR User -->|Identity & Session| GSA[Global Secure Access Edge] GSA --> SaaS[SaaS / Entra Apps] GSA --> PrivateApp[Private App Connector] User -->|Encrypted Tunnel| VPN[VPN Gateway] VPN --> VNet[VNet Resources] VNet --> PE[Private Endpoint] OnPrem --> ER[ExpressRoute] ER --> VNet

Nothing here replaces anything else.
Each path exists because a different thing is being trusted.

Real‑World Impact

Design decisions

GSA is excellent for user‑to‑app access
VPNs remain necessary for operator and infrastructure access
Private Endpoints harden services, not users
ExpressRoute belongs in transport conversations, not access debates

Trying to standardise on one tool across all four roles is how complexity leaks.

Operational reality (Day‑2)

GSA inherits Entra ID’s availability and failure modes
VPN access can be deliberately isolated from identity outages
Private Endpoint sprawl becomes a DNS and lifecycle problem
ExpressRoute incidents are rare, and brutally visible when they happen

These aren’t theoretical differences.
They show up during incidents and audits.

Two Scenarios Where GSA Should Not Be the Primary Control

1. Privileged and Emergency Operator Access

Examples:

Break‑glass access to IaaS hosts
Network appliance management planes
Recovery access during identity incidents

GSA assumes:

Entra ID is healthy
Policy evaluation is reachable
Microsoft’s edge is available

For operator access, those assumptions are unacceptable.

🍺

Brewed Insight:

Human operators managing infrastructure should not depend on the same identity edge that protects end‑user applications.

This is where a tightly scoped admin VPN isn’t legacy, it’s deliberate risk separation.

2. Environments With Hard Regulatory or Sovereignty Constraints

Examples:

Defence or restricted government workloads
Sovereign environments with constrained control planes
Architectures where identity plane dependency must be minimised

GSA requires:

Continuous Entra ID control plane access
Microsoft‑managed enforcement infrastructure

In some environments, that alone disqualifies it.

🍺

Brewed Insight: If the identity control plane cannot be assumed available or permissible, identity‑centric access cannot be the edge. No amount of policy elegance compensates for a violated assumption.

Gotchas & Edge Cases

GSA does not eliminate the need for Private Endpoints
Identity outages become access outages if you over‑centralise
ExpressRoute is often misused as a security boundary, it isn’t one
DNS design becomes more critical as access models diverge

Misunderstanding these boundaries is how architectures become fragile.

Best Practices

Start every access discussion by naming what is being trusted
Use GSA where identity context genuinely adds value
Keep operator access isolated from user access paths
Treat Private Endpoints as service hardening, not authorisation
Evaluate ExpressRoute on transport requirements alone

Coexistence is not compromise.
It’s architectural clarity.

🍺

Brewed Insight:

Global Secure Access doesn’t replace your network.
It replaces your default assumption that users must join it, and nothing more.

Knowing where that boundary ends is what separates mature designs from fashionable ones.

Learn More

What Global Secure Access Actually Is (and What It Is Not)

Thu, 12 Mar 2026 00:00:00 +1100

Most engineers approach Global Secure Access (GSA) the same way they approached VPNs.

They look for the tunnel.
They look for the IP range.
They ask where the packets go.

That instinct isn’t wrong, it’s just anchored to the wrong problem.

Global Secure Access isn’t trying to improve connectivity.
It’s trying to reduce the risk created by long‑lived trust decisions.

Once you see that, the rest of the architecture snaps into focus.

The Mental Model

The common assumption

The prevailing assumption is that GSA is:

A cloud‑hosted VPN replacement
A proxy with identity layered on
Another option for getting users “inside” the environment

Even well‑run VPNs reinforce this idea: authenticate strongly up front, then rely on the network to carry trust forward.

Why this breaks down

VPNs, even modern ones with MFA, make a single, high‑impact decision:

“This user and device are trusted. Keep them connected.”

What they’re bad at is withdrawing that trust when conditions change.

Device posture degrades
Risk signals increase
Credentials are abused mid‑session

The network stays up anyway.

GSA exists to collapse that decision latency.

How It Really Works

At its core, Global Secure Access is an identity‑centric access broker.

Its primary job is not to move traffic efficiently, but to continuously evaluate whether a session should still exist.

That evaluation is driven by:

Identity — Entra ID users, groups, and claims
Session context — device compliance, location, risk signals
Policy — Conditional Access and security profiles

If and only if, policy allows, GSA facilitates connectivity via Microsoft’s global edge.

Transport happens, but it’s not the point.

Access brokering vs network transport

This distinction is where most designs go wrong.

Layer	What it actually owns
Identity & Signals	Entra ID, device state, risk engines
Access Decisions	Global Secure Access
Transport	Microsoft global edge + existing paths
Application Trust	App‑level auth and authorisation

GSA does not replace:

Application authentication
Network routing design
Your underlying connectivity primitives

It replaces the assumption that connectivity equals trust.

Real‑World Impact

The business risk it actually reduces

Even a “good” VPN leaves one major risk intact:

A compromised user session remains powerful for too long.

Once connected, VPN users often gain:

Broad network reachability
Stable access that outlives changing risk conditions
Trust that is hard to revoke without full disconnection

GSA changes this by making access:

Explicit — scoped to apps, not networks
Session‑aware — continuously evaluated
Revocable — policy changes take effect mid‑flight

This reduces blast radius and shortens the window between something becoming unsafe and access being removed.

How this changes what you design and operate

You stop designing around “who gets on the network” and start designing around:

Which sessions are allowed right now
Under what conditions access should terminate
How quickly policy reacts to signal changes

Operationally, day‑2 effort shifts from network stability to decision quality.

Implementation Examples

GSA configuration is anchored in identity and policy, not routing tables.

Conceptual access flow

flowchart LR User[User Device] Edge[Microsoft Global Edge] GSA[Global Secure Access] Entra[Entra ID + Signals] App[Target Resource] User --> Edge Edge --> GSA GSA --> Entra Entra -->|Decision| GSA GSA -->|If allowed| App

The key observation:
The decision loop is short, and it repeats.

Policy as a control surface (illustrative)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "conditions": {
 "users": {
 "includeGroups": ["Engineering"]
 },
 "signInRiskLevels": ["low"],
 "devices": {
 "filter": "device.isCompliant -eq true"
 }
 },
 "grantControls": {
 "operator": "AND",
 "builtInControls": ["compliantDevice"]
 }
}

This isn’t special because it’s Conditional Access.
It’s important because GSA enforces these decisions continuously, not just at sign‑in.

Gotchas & Edge Cases

GSA will not save a weak identity posture
Poor device compliance or noisy risk signals will cause real outages, fast.
Protocols that assume broad network reach struggle
GSA rewards explicit app exposure, not ambient access.
Mis‑scoped policy fails hard
Identity‑driven systems don’t degrade gracefully; they deny decisively.
Preview behaviour matters
GSA is still evolving, assumptions must be validated against current service behaviour.

Best Practices

Treat GSA as a control plane, not a data plane
Design policies around revocation speed, not just access grants
Keep access scopes narrow and explicit
Assume sessions will be re‑evaluated and interrupted
Instrument and review access decisions as a security signal

🍺

Brewed Insight: A VPN asks, “Can this user connect?” Global Secure Access keeps asking, “Should this session still exist?” That difference isn’t networking, it’s risk management.

Learn More

Why the Traditional Network Perimeter is Disappearing

Tue, 10 Mar 2026 00:00:00 +0000

The traditional network perimeter didn’t fail overnight.

It faded, quietly, as organisations kept asking it to do jobs it was never designed for.
Not because security teams were wrong, but because the environment changed faster than the trust model.

Most enterprises still have a perimeter.
The problem is that many still treat it as authoritative.

The Mental Model

The common assumption

The long‑standing assumption goes something like this:

If a user is on the corporate network, we can trust them more.

That assumption underpins:

VPN‑centric access models
“Internal” vs “external” application classifications
Firewall rules as primary user controls
Security reviews anchored on ingress paths

It’s not reckless. It’s conservative.
And increasingly, it’s misleading.

Why it breaks

This model assumes:

Network location is a stable signal
Users reliably traverse centralised controls
IP addresses approximate identity

In modern enterprises, none of these hold consistently, especially under change.

How It Really Works

The perimeter didn’t move to the cloud.

It lost its authority as the default trust boundary for users.

SaaS dissolved application ownership

Most critical applications are no longer behind your firewall:

Microsoft 365
Salesforce
ServiceNow
GitHub

You don’t own their networks. You don’t control their ingress paths.
Routing users “inside” first doesn’t increase trust, it just adds friction.

The applications that matter most are now outside the perimeter by design.

Remote work normalised untrusted networks

Users now work from:

Home broadband
Shared Wi‑Fi
Mobile networks
Client environments

Each introduces:

IP churn
Carrier‑grade NAT
Shared address space

Network location stopped being a reliable indicator of who a user is or how they’re working.

Cloud platforms removed static boundaries

In Azure:

IPs are ephemeral
Services scale dynamically
Platform traffic often bypasses traditional inspection

You can still draw boundaries, but they don’t stay still, and they don’t answer identity questions.

The real shift

The perimeter still exists.

What’s changed is that it no longer answers the most important question:

Should this user be allowed to do this right now?

Visualising the Shift

This is the practical change most architectures are grappling with.

flowchart LR User[User] Device[Endpoint] Network[Network Location] Identity[Identity & Context] App[SaaS / Cloud App] User --> Device Device --> Network Device --> Identity Network -. signal .-> Identity Identity --> App

The network hasn’t disappeared, it’s been demoted.

It’s now a signal, not the decision point.

Real‑World Impact

The most damaging failures of the perimeter model aren’t breaches.

They’re operational.

Change becomes the primary failure mode

IP‑based trust struggles with:

New SaaS onboarding
Remote worker growth
Mergers and divestments
Incident‑driven access changes

Under pressure, teams respond predictably:

Broaden firewall rules
Extend VPN scopes
Add “temporary” exceptions
Defer clean‑up indefinitely

Security erodes not through attack, but through accommodation.

Defence in depth becomes defence by inertia

Layers remain in place because:

Removing them feels risky
Ownership is unclear
No single control is obviously broken

Over time, controls exist less to reduce risk and more to avoid uncomfortable conversations.

Users route around centralisation

When access paths are:

Slow
Fragile
Incompatible with how people work

Users find alternatives.

Architectures that assume compliance instead of expecting bypass age badly.

Implementation Examples

Intentionally omitted.

This post focuses on why the perimeter has lost authority, not how to replace it.
Specific Azure controls, policies, and access patterns are covered later in this series once the trust model is clear.

Gotchas & Edge Cases

The perimeter still matters for workloads
East‑west traffic, data residency, and regulatory boundaries don’t disappear. This post is about user access, not service‑to‑service isolation.
Choosing a perimeter‑centric model isn’t negligent
It can be a valid business decision, but it must be treated as a conscious risk, not a safe default.
Legacy applications complicate everything
They don’t invalidate the shift; they increase the cost of ignoring it.

Best Practices (Design Consequences)

Treat network location as context, not authority
Assume users will access applications from outside your ideal path
Expect exceptions to accumulate under change, and design accordingly
If “being on the network” is still your primary trust signal, make the risk explicit

🍺

Brewed Insight: The perimeter didn’t disappear it lost the right to decide. Architects don’t have to abandon it, but they do have to stop pretending it’s neutral.

Learn More

Turning Migration Data into Ongoing Operational Insight

Thu, 05 Mar 2026 00:00:00 +0000

Most migration programmes end the same way.

The workloads are live, the cutover checklist is green, the war room dissolves and someone asks, “Do we still need the migration tooling?”

What usually follows isn’t a decision, it’s entropy. Access gets removed. Discovery exports get archived “somewhere”. The migration subscription is locked down or deleted. Six months later, operations teams are running production systems with less architectural context than the migration team had before the first move group.

That’s not an Azure problem. It’s a thinking problem.

The Mental Model

Common assumption:
Migration data is temporary scaffolding useful only until workloads are running in Azure.

Why it breaks:
Migration data captures something you almost never get in steady‑state operations: a deliberately curated view of what exists, why it exists, and what risks were accepted to get it there.

Once migration ends, that context does not get recreated by ops tooling. In most organisations, it degrades immediately.

Migration data isn’t scaffolding. It’s the baseline system of record for your cloud estate.

How It Really Works

During migration, teams assemble structured information almost as a side effect of delivery pressure:

Application and workload inventories
Dependency and blast‑radius assumptions
Business criticality and recovery expectations
Security classifications and compliance scope
Known risks, exceptions, and waivers
Sizing and cost assumptions at time of move

This data is:

Reviewed by humans
Signed off by stakeholders
Anchored to a known decision point

That combination is rare after go‑live. Post‑migration, most systems know what is running, but not why it was allowed to run that way.

If you delete migration data, you don’t lose history you lose decision context.

Migration Data as a System of Record

Calling this a “system of record” is a strong claim, so let’s be precise.

Migration data should be authoritative for:

Workload identity (what this thing is, not how it’s implemented)
Business intent (criticality, environment classification)
Accepted risk at time of migration
Original architectural assumptions

It should not try to replace:

CMDBs
Live configuration state
Observability or monitoring platforms

Those systems answer what is happening now. Migration data answers why this was allowed to exist in the first place.

That distinction matters operationally.

Real‑World Impact (Where This Actually Bites)

Discarding migration data has predictable consequences:

Change impact becomes guesswork
Platform updates, network changes, or security hardening exercises lack reliable blast‑radius context.
Risk gets rediscovered, not managed
Previously accepted exceptions resurface during audits or incidents with no evidence trail.
Compliance scope drifts
Teams argue about what’s in scope because original classifications are gone.
Cost optimisation loses its baseline
You can see spend, but not whether it deviated from original intent or assumptions.

This directly changes how you design handover from migration to operations. If the data isn’t preserved, ops teams inherit systems without the authority to explain or defend them.

Closing the Loop: Migration to Steady State

The practical shift is simple, even if organisations struggle with it:

Migration programmes must produce an operational artefact, not just running workloads.

That means:

Migration data persists beyond the project
It is discoverable by ops, security, and governance teams
It is updated when material architectural changes occur not continuously, not never

Think of migration as the first commit to your operational knowledge base. Deleting it is the equivalent of force‑pushing main to empty.

Ownership Is Not Optional

If ownership of migration data is undefined, the outcome is guaranteed: it rots or disappears.

In practice, ownership should sit with:

Cloud platform teams, or
Cloud enablement / landing zone owners

Not the migration factory. Not individual app teams.

Why? Because this data exists to support cross‑cutting decisions platform change, governance enforcement, risk acceptance, not day‑to‑day app operations.

If no team is accountable for keeping this context alive, the organisation will relearn the same lessons during every audit, incident, or major platform change.

Conceptual Architecture

The mechanics are deliberately boring. The behaviour is what matters.

flowchart LR A[Migration Discovery & Assessment] --> B[Curated Migration Dataset] B --> C[Platform & Ops Decisions] B --> D[Risk & Compliance Processes] B --> E[Architecture & Change Reviews] E -->|Material change| B

This is not about real‑time accuracy. It’s about ensuring that decisions always have access to original intent and accepted risk.

Implementation artefacts are intentionally omitted.
This is a business and operating‑model decision, not a technical one. The failure mode is not poor tooling, it’s deleting or ignoring the data entirely.

Gotchas & Failure Modes

Stale data is not the enemy
Silent deletion is. Old context with known age is still valuable.
Over‑precision kills adoption
Migration assessments are directional. Treat them as baselines, not forensic truth.
Access control is often overlooked
Migration datasets contain sensitive architectural detail. Secure them like production metadata.
“We’ll rebuild it later” never happens
If you don’t preserve it at migration time, you won’t recreate it accurately.

Best Practices That Actually Change Behaviour

Declare migration data an operational artefact at programme inception
Assign a named owning team before cutover
Preserve decisions, assumptions, and accepted risks not just inventories
Require updates only when architectural intent changes
Make the dataset easy to find, or it effectively doesn’t exist

🍺

Brewed Insight: Most organisations don’t lose architectural knowledge because people leave. They lose it because projects end. Migration data is how you stop your cloud estate from developing convenient amnesia.

Learn More

Migrating Databases and Applications with Minimal Disruption

Tue, 03 Mar 2026 00:00:00 +0000

Most migration failures don’t come from bad architecture.
They come from bad timing.

Not clock time, but execution order, cutover mechanics, and operational readiness. The plan looked solid. The landing zone was built. The data copied cleanly. Then production traffic hit a dependency you moved in the wrong order, or a rollback path that only worked in the slide deck.

This post is about that messy middle: the moment where applications and databases actually move, users are watching, and mistakes are no longer abstract.

The Mental Model

Common assumption:
“If we minimise downtime, we’ve minimised risk.”

Why it breaks:
Downtime is just the most visible failure mode. The more dangerous ones arrive later: silent data divergence, background jobs writing to the wrong place, partial cutovers that only fail under load, or rollbacks that reintroduce stale state.

Minimal disruption is not about speed.
It’s about controlled state change under pressure.

How It Really Works

At execution time, migrations are dominated by three forces:

1. Stateful gravity

Databases, message queues, caches, and file stores resist movement. The more writers they have, and the less you understand those writers the harder they are to move safely.

2. Hidden dependencies

Applications rarely depend on “a database”. They depend on:

connection strings baked into background services
scheduled jobs that wake up at inconvenient times
integration endpoints with implicit ordering
identity, secrets, and token lifetimes

These are usually discovered during cutover, not before it.

3. Operational coupling

Monitoring, alerting, backups, access paths, and runbooks are often tightly bound to the old environment. After cutover, they don’t fail loudly, they just stop protecting you.

Tooling can’t compensate for misunderstanding these forces. Sequencing and operational discipline decide the outcome.

Real‑World Impact

Execution choices directly shape:

Availability – partial cutovers tend to produce intermittent, credibility‑destroying failures.
Data integrity – dual‑write and sync windows introduce divergence risk that grows with time and load.
Reversibility – fast cutovers without a clean rollback path are one‑way doors.
Operational load – underprepared ops teams become the bottleneck exactly when time pressure is highest.

This is where migrations stop being engineering exercises and become risk acceptance decisions.

Dependency‑Aware Sequencing

A reliable rule of thumb is to migrate from least to most stateful, not from “simple to complex”.

A safer execution order usually looks like:

Supporting infrastructure
- Identity integrations
- Secrets and configuration sources
- Monitoring and logging pipelines
Read‑only or replayable components
- Reporting workloads
- Background processors with idempotency or reprocessing capability
Databases
- Replicas or continuous sync first
- Promotion only when confidence is earned
Primary application entry points
- APIs, front ends, ingress paths

This sequencing limits blast radius and preserves optionality when things get uncomfortable, which they will.

Visualising a Controlled Cutover

flowchart LR Users --> FrontEnd_Old FrontEnd_Old --> DB_Old DB_Old -->|Continuous Sync| DB_New FrontEnd_New --> DB_New FrontEnd_Old -.->|Traffic Shift| FrontEnd_New

The overlap here is intentional. Accidental overlap is where migrations fail quietly.

Cutover Patterns and Their Trade‑offs

Shadow Write, Single Read

Writes go to old and new
Reads stay on the old system
Short, tightly controlled promotion window

Use when: data correctness matters more than simplicity.
Be wary: every additional hour increases divergence and rollback complexity.

Replica Promotion

Managed replicas kept in sync
Connection strings flipped at cutover

Use when: replication health is observable and trusted.
Be wary: promotion confidence often exceeds replication reality.

Ingress Switch

DNS, Front Door, or Application Gateway redirects traffic
Backends are already warm

Use when: tiers are genuinely stateless.
Be wary: using this pattern to “hide” database uncertainty is a common mistake.

There is no universal best pattern, but there are patterns that are routinely misapplied under time pressure.

Operational Readiness Is Part of Execution

Before cutover, the following should already be true:

Alerts fire from the new environment
Backups are running and restorable
Break‑glass access works
On‑call teams know what “normal” looks like after the switch

If any of these are deferred until “after go‑live”, the migration isn’t ready it’s just optimistic.

Note: This post intentionally avoids low‑level implementation examples. At this stage, migrations fail far more often due to sequencing errors and untested operational assumptions than missing commands or misconfigured flags.

Gotchas & Edge Cases

Background jobs often reconnect faster than front ends and start writing early.
DNS caching undermines carefully planned traffic shifts.
Clock skew between environments breaks token validation at the worst possible time.
Rollback data is only useful if it’s consistent and recent.

These aren’t rare edge cases. They’re recurring patterns.

Best Practices

Optimise for reversibility first, speed second.
Treat cutover as a state transition, not a deployment.
Freeze schema changes during migration windows.
Prefer fewer, well‑planned cutovers over many “small” ones.
Practice cutover timing in non‑prod using real‑world latency and load, not ideal conditions.

🍺

Brewed Insight: If you wouldn’t accept this level of uncertainty during a DR failover, you shouldn’t accept it during a migration. Cutover is not a delivery milestone it’s an operational risk decision you’re accountable for long after the project ends.

Learn More

Aligning Azure Landing Zones with Migration Factories

Thu, 26 Feb 2026 00:00:00 +0000

Most Azure migration programmes don’t fail because Azure is hard.
They fail because two teams are optimising for different survival instincts.

The landing zone team is incentivised to reduce future risk.
The migration factory is incentivised to move workloads now.

Both are rational.
Together, they create predictable friction.

The Mental Model

Common assumption:
“If the landing zone is ready, migration can start.”

Why it breaks:
A landing zone is not a finish line. It’s a capability backlog.
Migration factories don’t wait for backlog completion, they run on waves, throughput, and external deadlines.

Treating platform readiness as a binary state forces one of two bad outcomes:

migrations stall waiting for “one last thing”, or
migrations proceed by bypassing the platform entirely.

Neither is accidental. Both are structural.

How It Really Works

Landing zones and migration factories are operating models, not deliverables.

The landing zone defines what behaviours the platform permits at a point in time.
The migration factory defines how quickly new behaviours are introduced.

When these models aren’t deliberately aligned, the faster one wins.
In practice, that’s almost always the migration factory.

At that point, the landing zone stops being a control surface and becomes a clean‑up exercise.

Real‑World Impact (Where This Gets Expensive)

Misalignment doesn’t just “cause issues”. It creates moments that are hard to unwind:

First production workload without central logging.
You never fully regain observability parity.
First identity exception for speed.
Every subsequent wave expects the same treatment.
First subscription built outside agreed patterns.
Retrofitting guardrails becomes a political negotiation, not a technical one.

These are not theoretical risks. They are irreversible decisions made under time pressure.

Migration Factories Are Not Tools

A migration factory is often reduced to:

Azure Migrate
A set of pipelines
A spreadsheet with wave numbers

That misses the point.

A migration factory is an operating rhythm:

defined waves and entry criteria
repeatable architectural decisions
explicit exception handling
a feedback loop into platform design

If the landing zone can’t operate at that rhythm, the factory will route around it quietly at first, then systematically.

Sequencing Capabilities Against Migration Waves

The alignment move that matters is sequencing platform capabilities against migration waves, not against a theoretical “target state”.

What this looks like in practice

timeline title Landing Zone Capabilities vs Migration Waves section Platform Capabilities Identity & RBAC Baseline : done Network Hub & DNS : done Central Logging : done Backup & DR Patterns : active PaaS Guardrails : planned section Migration Factory Wave 1 – Low Risk IaaS : done Wave 2 – Line of Business Apps : active Wave 3 – Regulated Workloads : planned

Wave 1 does not need everything.
But it does need a small set of non‑negotiables.

A hard line worth drawing

In most environments, central identity and logging should exist before any workload migrates.
If you skip those to gain speed, you’re not accelerating you’re borrowing against future outages and audits.

Contract Boundaries That Actually Hold Under Pressure

High‑throughput programmes define explicit contracts and enforce them.

Landing zone team commits to:

dates when specific capabilities become usable
supported and unsupported patterns (clearly)
stability guarantees during migration waves

Migration factory commits to:

using only supported patterns by default
declaring upcoming needs before waves begin
quantifying the business impact of missing capabilities

Anything outside the contract is an exception, with an owner, an expiry date, and a remediation path.

If you can’t say no cleanly, you don’t have a contract, you have a hope.

Gotchas & Failure Modes

Temporary exceptions fossilise.
If they aren’t time‑boxed, they become precedent.
Platform teams optimise for completeness.
Migration teams optimise for predictability. Confusing the two creates tension.
Security aligns to the wrong wave.
When controls arrive late, they’re perceived as blockers rather than enablers.

These are behavioural problems with technical consequences.

Best Practices

Treat the landing zone as a product roadmap, not a one‑off build
Define non‑negotiable capabilities for Wave 1 and defend them
Align capability delivery explicitly to migration waves
Design exception paths deliberately and measure how often they’re used
Re‑negotiate contracts after every major wave, not at programme end

🍺

Brewed Insight: If your migration factory is faster than your landing zone, it will build its own platform.
You’ll inherit it later, with interest.

Learn More

Network and Identity Dependencies That Break Migrations

Tue, 24 Feb 2026 00:00:00 +0000

Most migrations don’t fail because Azure can’t do the thing.

They fail because something still expects to talk to something else over a path, under an identity, via a trust relationship nobody explicitly designed and that assumption survives right up until cutover.

At that point, the migration plan stops being an execution document and starts being an incident report.

The Mental Model

Common assumption:
“If it works today, and we move it carefully, the dependencies will come along for the ride.”

Why it’s wrong:
Network and identity dependencies aren’t portable assets. They’re emergent properties of an environment that’s been evolving for years, sometimes decades, without strong boundaries.

On‑prem, those dependencies are tolerated because the environment is permissive by default.
In Azure, boundaries are explicit, evaluated continuously, and enforced whether you meant them to be or not.

Migration doesn’t create these problems. It exposes them.

How It Really Works

Most estates operate with three overlapping dependency layers:

Declared dependencies
Firewall rules, documented service accounts, known trusts.
Inherited dependencies
Transitive network access, group‑based permissions, domain‑wide assumptions.
Accidental dependencies
Scripts, scanners, batch jobs, agents, and “temporary” access that outlived the person who added it.

Only the first layer ever makes it into migration planning.

The other two are discovered late, usually under load, usually in production.

What This Looks Like in Practice

The migration plan covers A → B.

The outage is caused by everything else.

Real‑World Impact

1. Reachability Is a Chain, Not a Switch

In Azure, “can it talk?” depends on all of the following being true at the same time:

A valid route exists
NSGs allow the flow
Firewalls allow the flow
Private endpoints / service endpoints resolve correctly
The identity is authorised at the destination

A failure anywhere in that chain produces the same symptom: timeout.

If your migration validation only checks one layer, you’re not validating you’re effectively guessing.

2. Identity Coupling Is Usually the Hard Stop

In real environments, identity is often coupled to:

Machines instead of workloads
Apps authenticating as computer accounts.
Directories instead of scopes
Domain‑wide permissions where resource‑level access was intended.
Humans and systems sharing identities
Service accounts used interactively “just this once”.

These patterns don’t degrade gracefully.
They fail the moment you introduce isolation.

If you haven’t mapped identity flows explicitly, your migration risk is undefined. That’s not a technical issue; it’s a governance one.

3. Regulated and Hybrid Environments Amplify the Damage

In regulated estates:

Network paths are deliberately constrained
Identity permissions are layered and inherited
Security tooling relies on privileged, out‑of‑band access

This creates two compounding problems:

Automated discovery misses critical paths
Teams trust the output anyway

That false confidence is worse than ignorance. It locks timelines around assumptions that won’t survive first contact with reality.

Implementation Examples

Proving Network Dependencies with Virtual Network Flow Logs

ℹ️

NSG Flow Logs are being retired (end of support June 30), and Azure’s direction is clear:
Virtual Network Flow Logs (VNet Flow Logs) are now the supported way to observe traffic patterns at the network boundary.

This matters operationally, not just administratively.

VNet Flow Logs shift the question from “did the NSG allow it?” to “what traffic actually traversed the virtual network?” which is exactly what you need during a migration.

Example: enabling VNet Flow Logs at the virtual network level.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' existing = {
 name: 'savnetflowlogs'
}

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2021-02-01' existing = {
 name: 'vnet-production-01'
}

resource networkWatcher 'Microsoft.Network/networkWatchers@2021-02-01' existing = {
 name: 'NetworkWatcher'
}

resource vnetFlowLogs 'Microsoft.Network/networkWatchers/flowLogs@2023-09-01' = {
 parent: networkWatcher
 name: 'vnetflowlogs'
 location: resourceGroup().location
 properties: {
 targetResourceId: virtualNetwork.id
 enabled: true
 storageId: storageAccount.id
 format: {
 type: 'JSON'
 version: 2
 }
 }
}

What this changes in practice:

You observe real traffic paths, not just rule evaluation
Cross‑subnet and transitive flows become visible
Infrequent or “forgotten” dependencies show up over time
Migration validation shifts from intent to evidence

This is particularly valuable in hybrid environments, where traffic often enters the VNet in ways no one diagrammed.

Identity Reality Check: Application Permissions

Many migration blockers aren’t bugs, they’re permissions that were never questioned.

1
2


az ad app permission list \
 --id <app-registration-id>

Look for:

Directory‑wide permissions granted “temporarily”
Legacy APIs still in use
Permissions that only function because of on‑prem trust paths

If removing a permission scares the team, you’ve found a migration risk, not a feature.

Gotchas & Edge Cases

Transitive trust assumptions
Visibility ≠ authorisation. Azure will enforce the difference.
Hard‑coded allowlists
Often embedded in third‑party services and forgotten until traffic shifts.
Infrequent jobs
Monthly or quarterly processes that fail long after go‑live.
Flow log misinterpretation
Logs show that traffic flowed, not why it was allowed. Context still matters.
Discovery tooling bias
Encrypted traffic, conditional access, and just‑in‑time permissions routinely evade automated mapping.

Best Practices (Hard Rules)

If a dependency can’t be explained, treat it as high risk
If identity flows aren’t diagrammed, the workload isn’t ready to move
Validate under restricted network conditions, not permissive ones
Assume discovery tools are incomplete, design reviews must compensate
Delay migrations when identity uncertainty is high; rework costs more later

🍺

Brewed Insight: Migration isn’t about moving systems, it’s about forcing your environment to tell the truth.
Network and identity dependencies are where it usually lies the most.

Learn More

Discovering and Assessing at Scale with Azure Migrate

Thu, 19 Feb 2026 00:00:00 +0000

Large‑estate discovery usually starts with good intent and ends with a SharePoint folder no one wants to open.

Thousands of VMs. Hundreds of charts. Confidence scores everywhere.
And yet, no clearer answer to what should we migrate next or what’s safe to commit to.

Azure Migrate doesn’t struggle with scale because it can’t see enough.
It struggles because teams ask it to answer questions it was never designed to decide.

The Mental Model

Common assumption:

“If we discover everything thoroughly enough, the migration plan will reveal itself.”

Why it breaks:
Discovery creates evidence, not decisions. Azure Migrate describes the estate you pointed it at, faithfully and at volume, but it has no understanding of ownership, risk tolerance, political constraints, or deadlines.

At scale, more data without sharper intent doesn’t increase confidence.
It delays commitment.

The real skill is not discovering more.
It’s discovering just enough to make the next irreversible decision.

How It Really Works

Azure Migrate is best thought of as a distributed observation system with an opinionated reporting layer.

Appliances observe compute, storage, and performance signals
That data is normalised into Azure’s internal inventory model
Assessments apply assumptions to project Azure targets and costs

Those last two words matter: apply assumptions.

flowchart LR A[On‑prem / Other Clouds] --> B[Azure Migrate Appliances] B --> C[Observed Signals] C --> D[Assessment Assumptions] D --> E[Reports & Recommendations]

What Azure Migrate produces is not truth, it’s a scenario.
And scenarios are only as good as the questions they were built to answer.

Real‑World Impact

Design

Large, undifferentiated assessments push architects toward “average‑based” designs.
Averages erase the very workloads that drive platform decisions: spiky usage, licence‑bound systems, and business‑critical outliers.

If everything is assessed together, everything gets designed the same.

Reliability

Short or patchy performance histories create a dangerous illusion: high confidence with low representativeness. Month‑end, seasonal, and failure‑mode behaviour is routinely absent and rarely noticed until production.

Cost

The most over‑trusted output in Azure Migrate is right‑sized VM recommendations.

They are not wrong, they are conditional. Treating them as commitments rather than lower‑bound scenarios is how migration business cases quietly fall apart six months later.

Security

Discovery almost always surfaces forgotten systems.
That’s not just migration debt, it’s an exposure report you didn’t know you were running.

Implementation Examples

1. Scope Discovery to Force Thinking

Discovery boundaries should reflect decision boundaries, not network convenience.

Common scoping dimensions that actually matter:

Business domain or cost centre
Environment class (prod vs non‑prod)
Regulatory or data sensitivity zones

Creating multiple Azure Migrate projects is not overhead it prevents cross‑contamination of assumptions.

1
2
3
4


az migrate project create \
 --resource-group rg-migrate-finance \
 --name finance-migrate \
 --location australiaeast

If a group can’t explain why it shares a project, it probably shouldn’t share an assessment.

2. Use Assessments as Explicit Scenarios

Every assessment should answer a single, named question.

Examples:

“What’s the cost floor if we lift‑and‑shift Finance prod with no licence benefits?”
“What breaks if we assume 30% performance headroom instead of 50%?”

Encode those assumptions directly in assessment naming. Treat them as disposable models, not artefacts to defend.

If an assessment can’t be deleted without an argument, you’ve already over‑invested.

3. Translate Assets into Decision‑Ready Groups

Azure Migrate discovers assets. Migration requires cohorts.

The translation step is where most programmes stall because it’s organisational, not technical.

graph TD A[Discovered Inventory] --> B[Technical Filters] B --> C[Ownership & Risk Context] C --> D[Migration Cohorts]

Cohorts exist to enable decisions:

Can this move independently?
Who signs off the risk?
What failure is acceptable?

If those answers aren’t obvious, the grouping is wrong.

Gotchas & Edge Cases

Discovery without ownership leads to politically unusable data.
<30 days of history systematically under‑represents risk.
Disconnected networks fail silently, missing systems look like “clean estates”.
Assessment confidence scores measure data completeness, not decision safety.

Best Practices

Define the next decision before deploying an appliance.
Stop discovery once that decision can be made, even if coverage isn’t “perfect”.
Treat right‑sizing outputs as a floor, not a promise.
Use missing or inconsistent data as a risk signal, not something to smooth over.
Delete assessments aggressively; keep only those tied to active decisions.

🍺

Brewed Insight: Azure Migrate is excellent at telling you what you pointed it at.
The real architecture work is deciding when you’ve seen enough to move and having the discipline to stop looking.

Learn More

Why Enterprise Migrations Still Fail Before the First Cutover

Tue, 17 Feb 2026 00:00:00 +0000

Most enterprise cloud migrations don’t fail during cutover.

They fail quietly months earlier in planning workshops, governance meetings, and PowerPoint roadmaps, while everyone still believes progress is being made.

By the time the first workload is scheduled to move, the migration plan isn’t risky or immature. It’s structurally unexecutable.

That’s the uncomfortable truth most migration projects only realise after momentum is already gone.

The Mental Model

Common assumption:

“If we invest enough effort up front, execution will be straightforward.”

This assumption feels responsible. It’s also the root cause of many failures.

Enterprise migration planning treats early decisions as temporary scaffolding:

Discovery will improve later
Governance can be tuned post‑pilot
Delivery teams will adapt once constraints are clear

In practice, early decisions behave like hard architectural commitments. They constrain everything that follows, often before the organisation understands what it has committed to.

Planning doesn’t precede architecture.
Planning is architecture.

How It Really Works

Migrations fail early because intent is designed without accountability for execution.

Planning artefacts are optimised for:

Portfolio visibility
Cost forecasting
Executive sequencing
Partner acceleration

Execution is constrained by:

Identity boundaries and trust models
Network topology and egress paths
Security control enforcement
CI/CD ownership and permissions
Who is allowed to deploy what, where, and how

When those systems don’t align, the migration doesn’t “slow down”.
It becomes impossible to deliver without exceptions,, and exception‑driven delivery does not scale.

Structural Failure Modes (Locked In Before Cutover)

1. Discovery Fails by Design, Not by Accident

The problem isn’t that discovery is incomplete.
The problem is that enterprise discovery is structurally incentivised to be incomplete.

Discovery phases are usually:

Time‑boxed
Optimised for classification, not behaviour
Owned by teams without operational accountability

So critical realities surface late:

Authentication paths that double as integration hubs
“Low‑risk” apps that terminate shared identity
Data dependencies that cross assumed trust boundaries

These aren’t edge cases. They’re normal outcomes of shallow discovery operating under schedule pressure.

When discovery is optimistic, migration plans don’t degrade they collapse.

2. Organisational Boundaries Become Hard Technical Constraints

Infrastructure, security, and application teams often agree on outcomes but not on control.

What actually happens:

Security defines mandatory controls without owning delivery paths
Platform teams build landing zones without workload context
Application teams assume exemptions will be negotiable later

This doesn’t create tension, it creates deadlock.

Once those boundaries are encoded into Azure constructs (management groups, policies, network segmentation), the organisation’s silos become enforced by the platform itself.

At that point, delivery friction isn’t cultural. It’s architectural.

3. Early Governance Decisions Are the Most Dangerous Ones

The most damaging migration decisions are often made early because they feel abstract:

Management group hierarchy
Subscription strategy
Policy inheritance models
Network segmentation patterns

These choices:

Define who can deploy
Shape every pipeline
Determine how quickly teams can change

Changing them later is expensive because everything depends on them.

Technical mistakes can be refactored.
Governance mistakes propagate.

4. Planning Delivery as a Phase Guarantees Failure

A reliable predictor of migration failure is this sentence:

“We’ll build the platform first, then enable delivery.”

That creates a gap between:

What the platform allows
What workloads require
What teams are authorised and able to deploy

If a real workload cannot be deployed safely, repeatedly, and without special approvals in the first few weeks, the migration will devolve into exception management.

And exception‑driven migrations don’t finish.

Real‑World Impact

When these issues exist before cutover, the symptoms are consistent:

Landing zones that look compliant but host nothing real
Security reviews blocking “low‑risk” workloads
CI/CD pipelines that can’t pass policy enforcement
Migration waves that exist only in planning artefacts
Growing distrust between platform and application teams

By the time cutover is discussed, confidence is already gone.

Visualising the Failure Pattern

Most failed migrations follow this shape:

flowchart LR A[Migration Intent] --> B[Portfolio Plan] B --> C[Early Governance Commitments] C --> D[Platform & Landing Zones] D --> E[Actual Workload Behaviour] E -->|Mismatch| F[Exceptions & Rework] F -->|Accumulation| G[Delivery Paralysis]

The break doesn’t occur at cutover.
It occurs when real workloads first touch governance.

Example: When Governance Becomes a Delivery Blocker

A common early move is enforcing strict network and exposure controls before workloads exist.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


resource denyPublicIP 'Microsoft.Authorization/policyDefinitions@2021-06-01' = {
 name: 'deny-public-ip'
 properties: {
 policyType: 'Custom'
 mode: 'All'
 displayName: 'Deny Public IPs'
 policyRule: {
 if: {
 field: 'Microsoft.Network/publicIPAddresses/ipAddress'
 exists: true
 }
 then: {
 effect: 'deny'
 }
 }
 }
}

The policy itself isn’t wrong.

The failure occurs when:

Identity flows weren’t designed
Egress requirements weren’t validated
CI/CD pipelines don’t have a compliant deployment path
Ownership of exemptions is unclear

At that point, the organisation learns a hard lesson:
governance without executable delivery paths doesn’t improve security it simply halts change.

Gotchas & Edge Cases

Pilots harden into standards
Early “temporary” designs become permanent reference architectures.
Exception processes create shadow platforms
Teams will bypass blocked paths rather than wait indefinitely.
Accelerators amplify structural flaws
They increase speed, not correctness.

Best Practices That Actually Matter

Treat discovery as behavioural analysis, not inventory
Design governance with delivery teams in the room
Make at least one real workload deployable immediately
Delay irreversible decisions until constraints are visible
Measure success by repeatability, not policy coverage

Or more bluntly:

If your platform can’t host a real workload early, your migration plan is fiction.

🍺

Brewed Insight:

The single decision that most reliably guarantees migration failure is locking in governance before proving delivery.

Enterprises keep making it because governance feels safe, visible, and decisive while executable delivery feels messy and unfinished.

But cloud doesn’t forgive that inversion.

Learn More

Designing Observable, Programmable Azure Networks for the Future

Thu, 12 Feb 2026 00:00:00 +1100

Azure networks rarely fall over outright.
They drift.

Latency stretches just enough to trip timeouts. SNAT usage inches upward until one busy afternoon tips it over. Traffic takes a longer path than it did last week, and nobody notices until customers do.

If your networking strategy only detects outages, you’re designing for yesterday’s problems.

This post makes a deliberate argument: programmable Azure networks depend on observability first, and not the dashboard‑heavy kind. The kind that tells you when behaviour changes, not just when things break.

The Mental Model

The common assumption
“If the network is up and packets are flowing, it’s fine.”

Why it breaks
Azure networking is a distributed software system. Paths change, capacity shifts, policies evolve, and platform behaviour is opaque by default. Most failures are gradual and cumulative, not binary.

An observable network doesn’t ask: “Is it reachable?”

It asks: “Is it behaving the same way it did yesterday, and if not, do I know why?”

That shift matters because automation amplifies whatever assumptions you bake in. Automating a blind network just helps you fail faster.

How It Really Works

Azure already emits an enormous amount of network telemetry. The problem isn’t access — it’s signal selection.

At a practical level, network observability in Azure comes from four places:

Metrics that show pressure (latency, SNAT ports, throughput)
Logs that show decisions (NSG allows/denies, firewall policy matches)
Topology state that shows intent vs reality (effective routes, effective rules)
Platform events that show change (maintenance, scaling, backend movement)

Treating all of these as equal is a mistake. Observable design is about choosing behavioural signals that map to outcomes you actually care about.

If everything is a signal, nothing is.

The Control Loop (Not a Pipeline)

flowchart LR A[Azure Network Data Plane] --> B[Selected Telemetry Signals] B --> C[Central Analysis Layer] C --> D[Behavioural Baselines] D -->|Deviation| E[Decision Point] E --> F[Human or Automated Action] F --> A

This is a control loop, not a deployment pipeline.

The important design decision is the decision point. That’s where you choose whether a human, a runbook, or a policy engine gets involved — and under what conditions.

Real‑World Impact

Designing for observability changes concrete engineering decisions:

Reliability
You detect partial failure before it becomes customer‑visible.
Security
You notice traffic patterns changing, not just packets being blocked.
Cost
You see pressure building (egress, SNAT, firewall throughput) before it becomes an incident or a bill shock.
Change safety
You can observe blast radius instead of relying on change success messages.

Most importantly, it lets you automate safely. You’re no longer reacting to symptoms — you’re responding to trends.

What Signals Are Actually Worth Keeping

If you had to delete half your network telemetry tomorrow, these are the signals worth defending in Azure designs:

SNAT port utilisation on NAT Gateway or Load Balancer
Because exhaustion is silent until it isn’t.
NSG or Firewall deny rate trends, not individual denies
Because behaviour shifts matter more than single events.
Path length or next‑hop changes via effective routes
Because unexpected hair‑pinning kills latency and trust.

Everything else is secondary until you’ve made these observable and explainable.

Implementation Examples

Baseline Signal Emission (Portal)

For production Azure networks, this should be non‑negotiable:

NSG Flow Logs v2 enabled
Firewall logs sent to Log Analytics (if used)
Load Balancer and NAT Gateway metrics enabled
Diagnostics standardised across environments

This isn’t about dashboards. It’s about ensuring signals exist when you need to ask hard questions.

Declarative Observability with Bicep

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


resource nsg 'Microsoft.Network/networkSecurityGroups@2023-09-01' existing = {
 name: 'nsg-app-prod'
}

resource diag 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
 name: 'nsg-observability'
 scope: nsg
 properties: {
 workspaceId: logAnalytics.id
 logs: [
 {
 category: 'NetworkSecurityGroupFlowEvent'
 enabled: true
 }
 ]
 metrics: [
 {
 category: 'AllMetrics'
 enabled: true
 }
 ]
 }
}

This snippet is intentionally boring.
Observable networks are built from consistency, not cleverness.

Programmability comes later, once the signals are trustworthy.

Closing the Loop Without Hurting Yourself

Not every signal should trigger automation. In fact, most shouldn’t.

Good automation candidates:

Scaling NAT Gateway based on sustained SNAT pressure
Flagging unexpected route changes for review
Opening incidents with topology context attached

Bad automation candidates:

Reacting automatically to transient route updates
Blocking traffic based on short‑lived anomaly spikes
Remediating without understanding blast radius

The rule of thumb is simple:
If you wouldn’t trust the signal to wake you at 3am, don’t let it reconfigure your network.

Gotchas and Edge Cases

Control‑plane state often lags data‑plane reality
Azure platform changes can shift “normal” behaviour overnight
High‑cardinality logs can drown out the signals you care about
Observability costs money — design deliberately

Day‑2 networking failures are usually design omissions, not platform bugs.

Best Practices

Treat observability as a first‑class requirement, not an add‑on
Design signals around outcomes, not resource types
Separate telemetry, interpretation, and action
Baseline behaviour before you automate anything
Revisit observability whenever traffic patterns change

🍺

Brewed Insight: Automation doesn’t make networks safer — understood networks do.
Observability isn’t about seeing more, it’s about knowing what matters.

Learn More

Automating Network Deployments with Pipelines and APIs

Tue, 10 Feb 2026 00:00:00 +1100

Click‑ops feels safe. You can see the blades, double‑check the settings, and convince yourself that careful hands mean lower risk.

That illusion holds right up until the day you need to reproduce the same network in another environment, explain a change to an auditor, or roll back a broken update at 2am. At that point, the Portal stops feeling like control and starts feeling like guesswork.

Azure networking isn’t fragile infrastructure that needs to be protected from change. It’s software that expects change. Treating it otherwise is where most teams get burned.

The Mental Model

The common assumption
“Networks are too critical to automate. We should change them manually to reduce risk.”

Why it breaks
In Azure, every network object is an API‑managed resource with a lifecycle. Manual changes don’t reduce risk; they just move it into places you can’t see, review, or reliably undo.

The first things that fail aren’t packets or routes. They’re:

Environment consistency
Change traceability
Incident recovery
Organisational trust in the platform

Click‑ops doesn’t fail loudly. It fails slowly, then all at once.

How It Really Works

Azure networking lives entirely behind the Azure Resource Manager control plane. The Portal, CLI, PowerShell, SDKs, and pipelines all call the same APIs. There is no privileged path.

That leads to a few uncomfortable truths:

Manual and automated changes are technically identical
The Portal offers convenience, not safety
Desired state is something you must define explicitly
Repeatability is a design choice, not a default

Once you accept that, automation stops being an optimisation and becomes the baseline operating model.

Idempotency Is Not “We Use Templates”

Idempotency is often claimed and rarely achieved.

Real idempotency means you can apply the same deployment repeatedly and always land in the same state, regardless of what happened before. In practice, many teams have templates but still allow:

Manual subnet edits “just this once”
Emergency NSG rules added in the Portal
Partial deployments scoped too broadly or too narrowly

That’s not idempotent. That’s false confidence.

Automation only works when templates are the source of truth and drift is treated as a fault, not a convenience.

Real‑World Impact

This mindset changes how you operate networks day to day.

Design shifts from “build it carefully” to “make it reproducible”. Deployments move from one‑off events to routine, reviewable changes. Rollbacks become redeployments, not memory tests. Audits become queries against Git history instead of archaeology through Activity Logs.

Most importantly, networks stop being special. They become part of the same delivery system as everything else.

That’s usually the moment teams realise where their real bottleneck was.

Automation Flow (Deliberately Boring)

flowchart LR Commit[Engineer commit] --> Repo[Git repository] Repo --> Pipeline[Deployment pipeline] Pipeline --> ARM[Azure Resource Manager API] ARM --> Network[Azure network resources]

This diagram is intentionally dull. If your network delivery relies on anything more exotic than controlled API calls with identity, review, and logging, you’re adding risk, not reducing it.

Implementation Examples

Declarative Network Definition with Bicep

This example is simple by design. The value is in what it enables, not in how clever it is.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


param location string = resourceGroup().location
param vnetName string
param addressSpace string = '10.10.0.0/16'

resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
 name: vnetName
 location: location
 properties: {
 addressSpace: {
 addressPrefixes: [
 addressSpace
 ]
 }
 subnets: [
 {
 name: 'workload'
 properties: {
 addressPrefix: '10.10.1.0/24'
 }
 }
 ]
 }
}

Applied repeatedly, this deployment converges the environment back to the declared state. That’s the foundation for safe change.

Pipeline‑Driven Deployment

In a pipeline, network changes should be:

Reviewed like application code
Deployed using managed identities
Logged automatically
Reproducible on demand

A minimal example using Azure CLI:

1
2
3
4


az deployment group create \
 --resource-group rg-network-prod \
 --template-file main.bicep \
 --parameters vnetName=vnet-prod-core

Same command, every environment. Parameters change. Behaviour doesn’t.

Safe Rollout and Rollback (What Actually Works)

Rollback plans that involve “log into the Portal and fix it” are not plans. They’re optimism.

Effective strategies include:

Using what‑if to understand blast radius before deployment
Scoping deployments narrowly to reduce unintended impact
Versioning network code alongside application releases
Rolling back by redeploying the last known‑good commit

Rollback is not reversing actions. It’s reasserting state.

Gotchas and Edge Cases

Some network changes are inherently disruptive and automation won’t make them safe
Long‑standing manual drift will eventually collide with templates
Dependency ordering still matters, especially with private endpoints
Preview API versions can change behaviour unexpectedly

Automation forces these realities into the open. That’s a feature, not a flaw.

Best Practices

Treat network definitions as product code
Enforce version control and pull‑request reviews
Make pipelines the only supported change path
Use incremental deployments with explicit scope
Assume drift will happen and design to correct it

If the Portal is your backup plan, it’s already your primary risk.

🍺

Brewed Insight: If a team says they “use Bicep” but still rely on the Portal for urgent fixes, the problem isn’t tooling. It’s that their deployment model and engineering culture are out of alignment.

Learn More

Routing as Code with Azure Route Server and Policy‑Based Routing

Thu, 05 Feb 2026 00:00:00 +1100

Most routing incidents aren’t caused by bad math or broken protocols.
They’re caused by unclear intent — nobody can confidently answer why traffic takes a particular path right now.

In Azure, routing is no longer a background configuration you “set once and forget”. It’s an evolving control surface, shaped by software, scale events, and failure domains. If you’re still treating routing like static infrastructure, you’re designing blind.

The Mental Model

The common assumption

Routing is:

A deterministic outcome of prefixes
Mostly static
Something you “finish” early in a design

Once the tables look right, you move on.

Why this breaks

Azure networks are living systems:

Routes appear and disappear dynamically
Control planes make decisions faster than humans can react
Multiple teams influence traffic paths, often unintentionally

The result is fragile certainty — everything looks fine until a route is withdrawn, a UDR is reused, or a firewall scales differently than expected.

How It Really Works

Think of Azure routing as two distinct software responsibilities:

1. Reachability (dynamic)

This is decided by:

System routes
BGP‑learned routes from ExpressRoute, VPN, or Azure Route Server

Azure Route Server doesn’t “optimise” traffic. It injects and withdraws reachability information into the VNet routing plane, based on what its BGP peers advertise. When a peer stops advertising a prefix, Azure stops believing that path exists.

That behaviour matters during failure — not during steady state.

2. Intent (static, but explicit)

This is enforced using:

User Defined Routes (UDRs)
Subnet‑level scoping
Next‑hop selection

UDRs don’t care why a destination exists. They simply say: if traffic is headed here, it must go that way.

The key insight:
BGP answers “where can I go?”
UDRs answer “where am I allowed to go?”

Architecture Overview

flowchart LR AppSubnet[App Subnet] Firewall[NVA / Firewall] RouteServer[Azure Route Server] ER[ExpressRoute / VPN] Internet[Internet] AppSubnet -->|UDR: default route| Firewall Firewall --> RouteServer RouteServer -->|BGP learned prefixes| Firewall Firewall --> ER Firewall --> Internet

This isn’t about elegance. It’s about predictability under change.

Real‑World Impact

Designing routing this way changes how you operate:

Failure is signalled, not hidden
When an NVA or SD‑WAN appliance stops advertising routes, Azure adapts immediately. There’s no stale static route pretending everything is fine.
Blast radius becomes intentional
Small, scoped route tables mean one bad decision doesn’t rewrite half the VNet.
Routing changes become reviewable
When UDRs and BGP configuration are defined as artefacts, you can reason about diffs, intent, and rollback — not just outcomes.
Incident response gets faster
Engineers debug effective routes, not portal click history.

Implementation Examples

Azure Portal – Where This Actually Bites

Operationally important checks (often missed):

Is route propagation enabled where you expect dynamic routes?
Are UDRs unintentionally overriding critical BGP paths?
Do effective routes differ between subnets that “should” be identical?

Most production routing issues show up here — not during deployment.

Bicep – Making Routing Intent Explicit

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


resource routeTable 'Microsoft.Network/routeTables@2022-09-01' = {
 name: 'rt-app-egress'
 location: resourceGroup().location
 properties: {
 disableBgpRoutePropagation: false
 routes: [
 {
 name: 'force-egress-firewall'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.10.0.4'
 }
 }
 ]
 }
}

The value here isn’t the route itself — it’s that intent is now inspectable:

Why all egress?
Why this next hop?
What breaks if it’s removed?

That conversation is the win.

Gotchas & Edge Cases (Where Designs Usually Fail)

UDRs override BGP — always
If a UDR points to a dead next hop, Azure will happily black‑hole traffic. Dynamic routing will not save you.
Asymmetric routing isn’t theoretical
It happens the moment inbound and outbound paths are controlled by different teams or constructs.
Shared route tables amplify mistakes
Reuse feels efficient until one “small change” alters traffic for dozens of subnets.
Route Server adds complexity you must own
If you don’t actively test route withdrawal scenarios, you’re just hoping it works.

Best Practices

Use Azure Route Server only when dynamic reachability actually matters
Keep UDRs small, scoped, and boring
Test failures by withdrawing BGP routes — deliberately
Treat effective routes as a first‑class debugging tool
Document why a routing decision exists, not just the prefix

🍺

Brewed Insight: If your routing design only works when nothing changes, it’s not a design — it’s a coincidence.

Learn More

Intent Is the New Topology: Azure Virtual Network Manager in Practice

Tue, 03 Feb 2026 00:00:00 +1100

Most Azure networks don’t fail loudly. They drift.

Not because engineers are careless, but because intent lives in people’s heads, while configuration lives in dozens of VNets, spread across subscriptions, regions, and teams.

Azure Virtual Network Manager (AVNM) exists for one reason:
to close that gap.

This post argues a clear position:

Once your Azure network spans multiple teams or subscriptions, per‑VNet configuration becomes an operational liability, and intent‑based networking stops being a “nice to have”.

The Mental Model: From Ownership to Obligation

The assumption we need to kill

If you squint, most Azure networks are still designed like this:

VNets own their peerings
Subnets own their NSGs
Teams own “their” part of the network

Automation helps, but the unit of control is still the VNet.

Why this fails in real organisations

At scale, networks aren’t owned they’re shared.

Platform teams define guardrails
Application teams create VNets
Security teams care about rules, not topology
Nobody owns the relationships between VNets end‑to‑end

The result is predictable:

Inconsistent connectivity
Security drift
Manual exceptions that never get undone

AVNM exists to move networking from ownership to obligation.

How AVNM Actually Changes the Game

This is the critical shift:

With AVNM, VNets no longer decide how they connect.
The platform decides, and VNets comply.

AVNM introduces a control plane where you declare:

Which VNets belong to the same connectivity domain
Which security rules are non‑negotiable
Where that intent is allowed to apply

VNets opt in by identity (tags, scope), not by bespoke wiring.

That’s not convenience.
That’s enforceable architecture.

Control Plane vs Data Plane (Why This Isn’t Magic)

flowchart LR AVNM[Azure Virtual Network Manager
Control Plane] NG[Network Groups] CFG[Connectivity & Security Intent] subgraph DataPlane["Azure VNets (Data Plane)"] Hub[VNet - Hub] Spoke1[VNet - Spoke] Spoke2[VNet - Spoke] end AVNM --> NG NG --> CFG CFG --> Hub CFG --> Spoke1 CFG --> Spoke2

A few truths worth stating plainly:

AVNM does not carry traffic
It does not dynamically react to failures
Nothing happens until you deploy a configuration

That explicit deployment step is the point.
It’s where intent becomes a controlled change, not background magic.

Scoping Is a Power Tool (And a Loaded One)

AVNM is scoped to a management group or subscription.
That scope defines:

Which VNets can be grouped
Where intent can be enforced
Your maximum blast radius

Here’s the uncomfortable reality:

A mis‑scoped AVNM can break every VNet it governs correctly.

Examples I’ve seen in the wild:

A connectivity config deployed at the wrong management group, flattening carefully segmented landing zones
Security Admin Rules unintentionally overriding workload‑specific NSGs across dozens of subscriptions
Platform teams granting AVNM access “temporarily” and never revoking it

AVNM should be treated like:

Azure Policy assignments
RBAC at management group scope

Rare, deliberate, and boring, by design.

Connectivity Across Subscriptions: Where AVNM Becomes Mandatory

This is the point where AVNM stops being optional.

Without AVNM

Cross‑subscription peering requires coordination and trust
Consistency relies on documentation and hope
New VNets are snowflakes until someone remembers to wire them in

With AVNM

Network Groups span subscriptions
Connectivity intent applies uniformly
New VNets inherit behaviour automatically

The key change isn’t technical, it’s organisational:

Application teams no longer need permission to design the network.
They only need permission to join it.

That reduces friction and risk, which is a rare combination.

Implementation Example: Opt‑In by Identity, Not Wiring

This example isn’t about syntax it’s about behaviour.

Define AVNM at platform scope

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


resource avnm 'Microsoft.Network/networkManagers@2023-11-01' = {
 name: 'corp-avnm'
 location: 'australiaeast'
 properties: {
 networkManagerScopeAccesses: [
 'Connectivity'
 'SecurityAdmin'
 ]
 networkManagerScopes: {
 managementGroups: [
 '/providers/Microsoft.Management/managementGroups/corp'
 ]
 }
 }
}

This establishes who is allowed to define intent.

Define a Network Group using tags

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


resource spokeGroup 'Microsoft.Network/networkManagers/networkGroups@2023-11-01' = {
 parent: avnm
 name: 'spokes'
 properties: {
 memberType: 'VirtualNetwork'
 membershipCriteria: [
 {
 criterionType: 'Tag'
 tagName: 'NetworkRole'
 tagValue: 'Spoke'
 operator: 'Equals'
 }
 ]
 }
}

The important outcome:

App teams create VNets
They apply a tag
The platform enforces connectivity and security

No tickets.
No peering spreadsheets.
No “did you remember to…”.

Day‑2 Reality: What Actually Changes

Design

You design connectivity domains, not diagrams
Architecture reviews focus on intent, not implementation detail

Operations

Drift is corrected by redeploying intent
Network changes become auditable events
Rollback is a config redeploy, not a forensic exercise

Failure modes

Bad intent propagates fast
Good intent scales effortlessly

AVNM amplifies whatever maturity you already have.

Gotchas That Actually Matter

AVNM configurations deploy per region
Security Admin Rules always override NSGs
Dynamic groups live or die by tag hygiene
Existing peerings don’t disappear unless intent says so

The biggest risk isn’t technical.

It’s treating AVNM like a convenience feature instead of a governance boundary.

Best Practices (Hard‑Won, Not Theoretical)

Start with connectivity, not security
Scope narrowly, expand reluctantly
Treat tags as API contracts
Lock down who can deploy configurations
Document intent like you would policy

🍺

Brewed Insight: If your Azure network spans more teams than you can name, AVNM isn’t an optimisation it’s damage control.

Learn More

Control Plane vs Data Plane: How Azure Really Moves Traffic

Thu, 29 Jan 2026 00:00:00 +1100

Most Azure networking conversations eventually end up here:

“So where does the packet actually go?”

It’s a reasonable question and the wrong one.

In Azure, you don’t operate a network that forwards packets.
You operate a system that decides how packets should be forwarded, and Azure executes that decision on your behalf.

If that distinction feels subtle, it’s the root cause of a huge amount of confusion, bad designs, and painful troubleshooting.

The Mental Model That Needs Replacing

The inherited assumption

Even experienced cloud engineers often carry this implicit model:

Control plane = management APIs
Data plane = packets moving through virtual appliances
If traffic breaks, follow the packet

That model comes from environments where:

You owned the switches
You controlled the routing tables
The data plane was visible and inspectable

Azure looks similar, until it doesn’t.

Why this breaks down in Azure

In Azure:

You do not control the forwarding devices
You cannot observe the real data plane
You never program routing directly

Routing is deterministic but it’s not operator‑visible or operator‑programmable in the traditional sense.

You declare intent.
Azure compiles that intent into behaviour.

Once you accept that, a lot of “mysteries” stop being mysterious.

The Real Split: Decision vs Execution

Here’s the framing that actually works:

Control plane decides what should happen.
Data plane executes that decision at scale.

flowchart LR CP[Azure Control Plane
APIs, ARM, Policy] INTENT[Compiled Intent
Routes, NSGs, LB rules] DP[Azure Data Plane
Provider-managed fabric] CP --> INTENT INTENT --> DP

You interact almost exclusively with the control plane:

Azure Resource Manager (ARM)
Networking APIs
Policy and higher‑level abstractions

Azure owns the data plane:

The actual forwarding paths
The real routing state
The physical and virtual infrastructure

That data plane is intentionally opaque.

What Azure Abstracts Away (Deliberately)

Azure hides:

Physical topology
Hop‑by‑hop routing
Device‑level failure handling
Real packet paths

This isn’t a limitation.
It’s what enables:

Massive scale
Fast, global reconfiguration
Provider‑managed resilience

Yes, Azure exposes signals effective routes, flow logs, metrics.
But those are diagnostics of intent, not windows into the fabric.

Trying to reason about Azure like a visible network is like debugging Kubernetes by SSHing into nodes. You might learn something, but you’re fighting the platform.

What You Can Still Influence

Abstraction doesn’t mean loss of control.
It means control moves up a level.

You influence behaviour through:

Addressing and VNet boundaries
User‑defined routes (as intent, not tables)
Network Security Groups (policy, not firewalls)
Load balancer rules (outcomes, not flows)

You are shaping constraints, not paths.

This is why Azure networking feels declarative even when you’re not using explicit policy services.

Where Decisions Are Actually Made

Let’s be clear about responsibility boundaries.

Routing

You define desired next hops
Azure determines the actual forwarding implementation
“Effective routes” show outcomes, not live tables

Firewalling

NSGs are evaluated by the platform
You never touch the enforcement engine
Rule ordering is contractual, not procedural

Load balancing

You define distribution rules
Azure selects instances dynamically
Health probes influence decisions you don’t directly observe

In every case:

You declare what must be true, not how it’s achieved.

Why Packet‑Level Reasoning Fails

This is where experienced engineers often get stuck.

Common instincts that don’t translate well to Azure:

“Which hop is dropping the packet?”
“What does the routing table look like right now?”
“Let’s capture traffic at the firewall interface.”

These assume:

A stable, inspectable data plane
Deterministic, operator‑visible paths
Devices you can interrogate

Azure intentionally violates those assumptions.

When traffic fails, the cause is almost always:

Conflicting intent
Missing intent
Scope mismatch
Platform‑level precedence overriding expectation

Not a mysterious dropped packet in the fabric.

A Concrete Failure Pattern (Seen Too Often)

A common real‑world outage pattern:

A platform team introduces a broad NSG change at a shared scope
The rule is valid, tested, and correctly ordered
It unintentionally overrides workload‑specific assumptions in multiple VNets

From the workload perspective, “the network broke instantly.”

From Azure’s perspective, it did exactly what it was told.

This is a control plane failure, not a data plane one and packet tracing won’t save you.

Operational Consequences (Day‑2 Reality)

Once you internalise the split, operations change.

Design reviews

Look for intent collisions, not topology flaws
Ask “what enforces this?” before “where does this live?”

Incident response

Start with control plane state and recent changes
Validate effective configuration
Assume the data plane is faithfully executing declared intent

Change management

Small control plane changes can have massive impact
Rollback means restoring previous intent, not fixing devices

This is why Azure networking incidents often look instant and wide‑reaching.

They are.

What This Post Is Not About

To be explicit:

This is not about intent‑based policy design
This is not about automation pipelines
This is not a breakdown of specific routing services as code

This post is about thinking correctly before you design or debug anything.

🍺

Brewed Insight:

If you’re still asking where the packet went, you’re debugging the wrong system.

In Azure, the control plane is the system. The data plane is just the executor.

Learn More

Azure Networking Is Software‑Defined — Once You Design for That, Everything Changes

Tue, 27 Jan 2026 00:00:00 +1100

Most Azure networking designs don’t fail outright, they just slowly become harder to reason about. Changes feel risky. Costs creep up. Incidents are harder to explain after the fact.

In practice, that usually isn’t a tooling problem or a skills gap.
It’s a mental‑model mismatch: designing Azure networking as if it were virtual hardware, when it behaves like a distributed software system.

Once you design with that in mind, a lot of complexity simply stops being necessary.

The Mental Model

The common assumption

Azure networking is often treated as on‑prem networking, abstracted:

VNets behave like virtual LANs
Subnets define stable trust zones
Routes map to predictable forwarding paths
Firewalls act as network choke points

Get the topology right, and the system behaves.

Why this misleads

Azure doesn’t provide a static network fabric you configure and operate.
It provides a control plane where you declare intent, and the platform continuously reconciles that intent into runtime behaviour.

The gap between those two concepts intent vs implementation is where many designs quietly struggle.

How It Really Works

Azure networking is software‑defined networking (SDN) in a very literal sense:

Configuration is expressed entirely through APIs (Azure Resource Manager and provider services)
Enforcement happens across a distributed, platform‑owned data plane
Policy shapes behaviour more than topology
State is constantly re‑evaluated, converged, and corrected

You don’t manage links, switches, or tables.
You manage desired behaviour, and Azure decides how to make that true, today and tomorrow.

This is less like wiring a network and more like operating a distributed system.

A More Useful Way to Visualise It

flowchart LR A[Declared Intent
Bicep / ARM / Portal] B[Azure Networking Control Plane] C[Platform Data Plane] D[Observed Behaviour] A --> B B --> C C --> D B -. continuously reconciles .-> C

You can’t touch the data plane directly.
You can only change behaviour by adjusting intent.

That distinction explains a lot of “unexpected” Azure networking behaviour.

Real‑World Impact

This mental shift has real consequences for how you design and operate systems.

Design

Focus on outcomes (reachability, isolation, inspection), not clean diagrams
Subnets are constraints, not trust boundaries by default
Fewer bespoke routes and network tricks are usually better

Reliability

Change is convergent, not atomic
Temporary inconsistency is normal during updates
Understanding control‑plane timing matters as much as packet flow

Security

Security posture is the sum of overlapping policies
Platform defaults can matter more than explicit rules
Over‑segmentation often gives a false sense of control

Cost

Complex topology doesn’t buy resilience
The platform already provides redundancy duplicating it costs money without adding value

This directly affects how much you deploy, how often you touch it, and how confident you feel changing it later.

Implementation Example: Declaring Behaviour, Not Plumbing

A simple VNet declaration illustrates the contract you’re working with:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


resource vnet 'Microsoft.Network/virtualNetworks@2024-01-01' = {
 name: 'prod-core-vnet'
 location: resourceGroup().location
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.10.0.0/16'
 ]
 }
 subnets: [
 {
 name: 'workload'
 properties: {
 addressPrefix: '10.10.1.0/24'
 privateEndpointNetworkPolicies: 'Disabled'
 }
 }
 ]
 }
}

This code doesn’t:

Allocate interfaces
Fix forwarding paths
Guarantee traffic flow ordering

It declares constraints and intent. Azure continuously ensures runtime behaviour aligns with that intent, even as the underlying platform evolves.

That’s the SDN contract you design against.

Gotchas & Edge Cases

Behaviour can change over time without configuration drift
Implicit defaults often matter more than explicit settings
Multiple services can project policy onto the same data plane

If something feels “non‑intuitive,” it’s often because the design assumes stable internals that don’t exist.

Best Practices

Design for behaviour, not topology
Keep networking intent simple and explicit
Assume convergence, not instant change
Validate behaviour continuously, not just at deployment
Let the platform do what it’s already good at

If your design needs deep knowledge of hidden mechanics to remain safe, it’s probably too fragile.

🍺

Brewed Insight: Once you treat Azure networking like a software system you declare, rather than infrastructure you build, your designs get simpler and your day‑2 operations get much calmer.

Learn More

Wrapping Up 2025 – A Year Well Brewed

Mon, 15 Dec 2025 00:00:00 +1100

Another year down, another cup of coffee emptied and what a year this one has been.

This year has easily been one of the biggest for Brewed in the Cloud. I’ve written 16 series totalling 82 individual posts, each one fuelled by equal parts curiosity and caffeine. On top of that, I joined my first public event with Azure Back to School, was invited onto the I Am IT Geek YouTube Channel and PoV: You’re in Tech Podcast and, to top it all off, was honoured to receive my Microsoft Most Valuable Professional (MVP) award.

It’s been a year of writing, talking, and sharing all things Microsoft Azure — and one of immense personal and professional growth.

Balancing Consulting and Creativity

Balancing a full‑time consulting role while producing this content was no small feat. It’s always difficult to meet the demands of customer projects while wanting to give back to the community, but I’m incredibly fortunate to have the support of the cubesys team encouraging me along the way.

Making time for your creative craft is essential but equally, it should never feel like a chore. If it does, both your enjoyment and the community’s experience suffer. The goal is to share out of passion, not obligation, and to keep the process energising rather than draining.

A Major Milestone – Becoming a Microsoft MVP

One of the biggest highlights of the year was being recognised as a Microsoft Most Valuable Professional (MVP). It’s an incredible honour and something I’ve aspired to since starting Brewed in the Cloud. This recognition represents not just the content I’ve written, but the collaboration, conversations, and mutual learning we share across the Azure community every day. It’s a reminder that genuine knowledge sharing really does make an impact.

By the Numbers

This year, around 4600 unique users visited the site with just under 9000 page views, according to Google Analytics. Those numbers are far beyond what I expected when I first started this journey and it’s all thanks to those who stop by, read, comment, or reach out. Every click and message provides motivation to keep learning and sharing.

The cubesys team also had a massive year, being recognised as a Global Finalist for Community Impact at Microsoft Ignite 2025, and locally as a Cloud Finalist at the ARN Innovation Awards. To be part of a team delivering that level of community impact has been an absolute privilege.

Highlights from the Blog

A few series really stood out for me this year:

Essential 8 ML2 in Microsoft Cloud VDI:
This series was well outside my comfort zone, but by implementing and testing a lot of theory, I proved to myself that I can learn, adapt, and teach especially in moments when I might be hitting a creative block.
Mastering Azure DNS Solutions:
This one filled what I felt was a real gap in the community: explaining the range of Azure DNS options and how they apply in real‑world solutions. It connected with a lot of readers and reinforced how powerful clear, practical education can be.

Looking Ahead to 2026

Next year, I want to continue writing but start branching out into new mediums as well expect to see more video content and podcast‑style discussions, expanding how Brewed in the Cloud shares knowledge with the Azure community.

It’s time to brew up the next format and see where it takes us.

A Seasonal Note

As we close out 2025, I want to thank everyone who’s taken the time to read, share, or drop a comment through the year. Your support fuels this project more than you probably realise.

Have a safe and joyful holiday season and a great start to the new year I’ll be back in late January 2026 to kick things off again.

🍺

Brewed Insight: The community grows strongest when you create because you love it not because you have to. Keep your cup full, your curiosity alive, and the rest will take care of itself.

Thanks again for being part of this journey. Here’s to another well‑brewed year ahead.

Brewing the Latest Azure Landing Zone – Lessons from the Brew Bench

Thu, 11 Dec 2025 00:00:00 +1100

If the Azure Landing Zone (ALZ) journey is like brewing the perfect coffee, this post is that honest chat after you’ve over‑extracted a few cups. In real‑world deployments, organisations have to continuously juggle control vs agility, security vs delivery speed, and innovation vs governance.

After guiding multiple customers through the latest Enterprise‑Scale Landing Zone (ESLZ) and Microsoft Sovereign Landing Zone (SLZ) frameworks, common lessons have emerged. This post distils those takeaways — including a clearer approach to management group design and naming. Specifically, we’ll move away from calling a management group LandingZones and instead use Workloads to remove ambiguity in both design and conversation.

What Are We Talking About?

A Landing Zone in Azure is the blueprint for secure, scalable, and compliant cloud adoption. It’s not a single deployment but a framework built on key Cloud Adoption Framework (CAF) design areas:

Identity and access management
Network topology and connectivity
Resource organisation and governance
Security and compliance
Operations and monitoring

The Landing Zone defines how your cloud environment behaves — from management groups and policies to identity and network boundaries.

Traditional vs Sovereign Landing Zones

Traditional (Enterprise‑Scale) Landing Zone:
Focused on enablement and agility. Suitable for enterprises operating in standard Azure regions, balancing control with speed.
Sovereign Landing Zone (SLZ):
Brings in region‑specific compliance, isolation, and regulatory enforcement — designed for governments or regulated industries where data residency, evidence‑based compliance, and jurisdiction control are mandatory.

While the architectural philosophies overlap, their priorities differ: ALZ optimises for velocity, SLZ for assurance.

How It Works

Traditional Azure Landing Zone

A traditional ALZ uses modular design and automation-first governance, enabling global scaling across multiple regions and tenants.

Key building blocks:

Management group hierarchy aligned to business or environment structure
Centrally applied policies and RBAC for consistency
Shared platform services (network, monitoring, identity) in separate subscriptions
Continuous delivery pipelines or Infrastructure‑as‑Code via Bicep or Terraform

Sovereign Landing Zone

Building on the same logic, an SLZ adds:

Data residency enforcement and regional isolation
Restricted service sets and endpoints
Predefined compliance mappings (e.g. IRAP, PSPF, GDPR)
Enhanced auditing and evidence collection

Sovereign doesn’t replace ALZ — it’s a focused flavour built to satisfy regulatory obligations while maintaining enterprise governance principles.

Comparing Sovereign and Traditional Landing Zones

Business Requirement	Traditional Azure Landing Zone (ALZ)	Sovereign Landing Zone (SLZ)
Global scalability and flexibility	✅ Designed for global access across Azure regions	⚠️ Region‑restricted to authorised sovereign zones
Common compliance (ISO 27001, SOC2)	✅ Standard CAF policy packs with Defender for Cloud integration	✅ Adds regulated‑industry control sets and compliance mapping
Data residency and jurisdiction control	⚠️ Achievable by region choice and resource policies	✅ Enforced at tenant, policy, and network boundary levels
Operational speed and developer agility	✅ High, supports rapid release and CI/CD	⚠️ Controlled workflows and stricter approval gates
Evidence‑based auditing	⚠️ Manual or pipeline‑based evidence collection	✅ Pre‑mapped controls for audit frameworks, automatable evidence outputs
Service availability and integrations	✅ Full Azure catalogue available	⚠️ Restricted to approved sovereign service subset

Example Scenarios

Example 1 – Retail Expansion Across APAC
A multinational retailer needs consistent governance, global scalability, and moderate compliance.
➡️ Recommendation: Traditional ALZ with region‑specific policy tailoring. This supports rapid feature delivery while maintaining cost and security visibility.

Example 2 – Government Health Department
A state health agency must keep sensitive citizen data within national borders under IRAP and PSPF compliance frameworks.
➡️ Recommendation: Sovereign Landing Zone using Microsoft Cloud for Sovereignty. Isolated policy sets and private connectivity ensure data jurisdiction and audit readiness.

Real‑World Impact

Choosing between traditional and sovereign landing zones reshapes how platform, network, and security teams collaborate.

Deployment velocity: Sovereign adds rigor; traditional prioritises speed.
Platform ownership: Workload separation becomes critical so different teams can innovate without jeopardising compliance boundaries.
Maturity evolution: Organisations often start with a traditional landing zone, introducing sovereign constructs later as regulatory scope widens.

The most successful teams don’t treat these as opposites — they view sovereign controls as extensions of a mature governance posture.

Implementation Examples

Azure Portal – Management Group Structure

Define Your Management Group Hierarchy

Recommended baseline:
- Root
  - Platform (identity, connectivity, security, management)
  - Workloads (clearer term replacing “LandingZones”)
    - Corp
    - Online
    - Sandbox
    - Sovereign (for regulated or region‑restricted environments)
Why “Workloads”?
Using LandingZones as a management group name often confuses teams, because it overlaps with the conceptual ALZ itself.
“Workloads” better describes the environments (applications, services, data systems) running on the platform — giving clean separation between the Platform providing governance and the Workloads consuming it.
Deploy Your ALZ or SLZ Baseline
- Traditional ALZ setup from the Azure/Enterprise-Scale GitHub.
- SLZ variants from the Microsoft Sovereign Landing Zone repo.
Assign and Scope Policies Appropriately
- Platform MG → Core policies (Defender, diagnostics, RBAC).
- Workloads MG → Application/Environment controls or sovereign compliance packs.

Management Group Hierarchy – Platform and Workloads View

graph TD A[Root MG] --> B[Platform] B --> B1[Identity] B --> B2[Connectivity] B --> B3[Security & Management] A --> C[Workloads] C --> D["Corp (Traditional)"] C --> E[Online] C --> F[Sandbox] C --> G[Sovereign] G --> H[Protected Data Workloads] G --> I[Gov Cloud Services]

✅ Design takeaway:

Landing Zone = architectural framework and governance design.

Workloads = operational environments where real applications are deployed.
This naming keeps responsibilities, policies, and discussions clear between teams.

Gotchas & Edge Cases

Feature availability: Sovereign clouds lag slightly behind global Azure in service parity. Validate service lists before deployment.
Identity boundaries: Dedicated Azure AD tenants for sovereign clouds may require federated or external B2B setup.
Policy drift: Copying policies manually instead of version‑controlling changes disrupts ALZ upgrade paths.
Subscription sprawl: Workload owners often over‑provision subscriptions. Address this through CAF‑aligned naming and tagging standards.

Best Practices

Define business drivers first: Is data residency regulatory or preference? That decides ALZ vs SLZ path.
Automate compliance: Policies and governance artefacts should produce evidence directly usable by auditors.
Use Workloads as the separator: Platform = guardrails. Workloads = delivery spaces. Keep boundaries firm.
Parameterise everything: Build one template to deploy both ALZ and SLZ variants.
Integrate culture with architecture: Platform and security teams must agree on the definition of “secure enough”.
Version control your baselines: Store every policy set and blueprint like software releases.

🍺

Brewed Insight: Changing “LandingZones” to “Workloads” isn’t just semantics — it’s a clarity upgrade. Teams design and talk more effectively when they can distinguish the framework that governs from the spaces that consume. Whether sovereign or traditional, a well‑structured landing zone is like a good roast profile: consistent, intentional, and adaptable to taste.

Learn More

Brewing the Latest Azure Landing Zone – Cost, Scale, and Landing Zone Optimisation

Tue, 09 Dec 2025 00:00:00 +1100

Every cloud architect eventually faces a moment when they realise their Azure footprint is growing faster than their governance can keep up. Think of it as your data centre turning into an over‑caffeinated espresso machine — powerful, but prone to overflow without a well‑placed drip tray.

Landing Zones, both enterprise and sovereign flavours, must do more than deploy infrastructure at scale — they need to manage cost velocity with intent. This post focuses on how to keep your Azure Landing Zone (ALZ or SLZ) well‑tuned, ensuring growth without runaway spend or unnecessary complexity.

🔍 What is Cost and Scale Optimisation in Landing Zones?

At its core, cost and scale optimisation within an Azure Landing Zone is about controlling expansion without constraining capability.

The Azure Cloud Adoption Framework (CAF) divides design into several areas — management, governance, security, and platform operations — each with a cost impact.

Optimisation ensures your resource hierarchy (management groups, subscriptions, resource groups) aligns with your financial governance model.
Scaling responsibly means creating clear subscription boundaries for workloads, environments (dev/test/prod), or compliance zones.
In Sovereign Landing Zones (SLZ), optimisation frameworks extend into jurisdictional controls, where cost transparency must be aligned with data residency or sovereignty constraints.

By embedding FinOps principles and Azure Cost Management early in design, you turn reactive cost clean‑ups into proactive, measurable efficiency.

⚙️ How It Works

1. Subscription Growth and Split Patterns

Landing Zones typically adopt a subscription vending model — providing repeatable units that developers or ops teams can deploy within policy boundaries. The growth management model should consider:

Horizontal Scale: One subscription per workload or environment.
Vertical Scale: Dedicated subscriptions for shared services, monitoring, or networking.
Controlled Growth: Use Azure Policy or Blueprints to limit unauthorised subscription creation.

In enterprise environments, scaling is normally orchestrated through ALZ Accelerator templates or Terraform/Bicep pipelines that integrate subscriptions into governance structures automatically.

2. Management Group Cost Governance

Management groups enable aggregated cost insights and allow charge‑back/show‑back reporting across organisational units. Assign budgets, cost alerts, and policies at these layers for enterprise visibility.

Diagrammatically:

graph TD A[Root Management Group] --> B[Platform] A --> C[Landing Zones] B --> D[Shared Services Subscription] B --> E[Connectivity Subscription] C --> F[Workload Subscription 1] C --> G[Workload Subscription 2] A --> H[Management Group Policies: Cost, Budget, Tag Enforce]

Here, budget and tagging policies flow from the Root or Platform layers down to each subscription, maintaining consistency while allowing scale.

3. Tagging, Budgets, and FinOps Integration

Tags like Environment, BusinessUnit, and CostCentre drive accountability. Combine these with Azure Policy for mandatory tagging and integrate with Azure Cost Management + Billing APIs for financial automation.

Consider using:

Azure Monitor Workbooks for cost visualisation.
Power BI with Cost Management connector for cross‑subscription analysis.
FinOps Open Cost and Usage Specification (FOCUS) export formats for interoperability with other FinOps tooling.

For Sovereign Landing Zones, tagging can be extended with jurisdictional flags such as DataResidency=AU or ComplianceRegime=ACSC.

4. Aligning with Sovereign Controls

When operating under sovereign cloud models — such as Azure Australia Central or government‑restricted environments — ensure all cost and telemetry exports remain within the sovereign boundary.
Use region‑specific APIs, endpoints, and compliance‑approved tooling for cost analysis and monitoring. This ensures financial data sovereignty aligns with jurisdictional regulations without compromising insight or automation efficiency.

🌏 Real‑World Impact

Let’s say you’re operating a multi‑region landing zone spanning public sector workloads in Australia and New Zealand. Without enforcing subscription separation or tagging, shared resource costs start blending across compliance boundaries.

By introducing structured hierarchy and budget controls:

Visibility improves — you can now break down cost by agency, workload, or data jurisdiction.
Forecasting accuracy increases — line‑of‑business teams own their consumption.
SLZ frameworks seamlessly align policy enforcement with local regulatory reporting, helping meet sovereign requirements without sacrificing agility.

This balance between decentralised empowerment and central oversight is the hallmark of a mature Azure Landing Zone.

🧩 Implementation Examples

Azure Portal Walkthrough

Navigate to Cost Management + Billing → Cost Alerts → + Add
Create a budget scoped to your management group or subscription
Assign an action group to notify or trigger automation (e.g. Logic App for tagging enforcement)
Validate budget alignment within Azure Policy Compliance view

Bicep Example – Cost Governance

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


param managementGroupId string
param costThreshold float
param emailAddress string

resource budget 'Microsoft.Consumption/budgets@2021-10-01' = {
 scope: managementGroup(managementGroupId)
 name: 'mg-budget'
 properties: {
 category: 'Cost'
 amount: costThreshold
 timeGrain: 'Monthly'
 timePeriod: {
 startDate: '2025-01-01T00:00:00Z'
 endDate: '2025-12-31T23:59:59Z'
 }
 notifications: {
 alertWhenOver: {
 enabled: true
 operator: 'GreaterThan'
 threshold: 90
 contactEmails: [emailAddress]
 }
 }
 }
}

This script deploys a management group‑scoped budget with alerting, ideal for ALZ cost governance automation.

🧱 Gotchas & Edge Cases

Tag sprawl can become a problem — align mandatory tags to a central schema stored in a repo or CMDB.
MFA/Privileged Access blocks automation — ensure service principals used for budget or policy deployment have least‑privilege roles.
Sovereign clouds may have feature gaps in cost export or telemetry capabilities. Validate region‑specific limitations before implementing FinOps pipelines.

✅ Best Practices

Enforce mandatory tags through policy at the Platform or Corp MG level.
Use budgets and alerts at management groups — not just subscriptions.
Integrate deployment pipelines with cost tracking for transparency.
Leverage Azure Policy exemptions sparingly to maintain consistent governance.
Adopt CAF Cost Management design considerations early in Landing Zone evolution.
For SLZ, map cost objects to data sovereignty boundaries to simplify audit readiness.
Ensure cost data exports stay within sovereign boundaries when required by regulation.

🍺

Brewed Insight: A strong cloud strategy isn’t just about speed — it’s about sustainability.
Like a well‑balanced brew, your Landing Zone should scale smoothly, with no bitter aftertaste of surprise invoices.

📚 Learn More

Brewing the Latest Azure Landing Zone – Extending to Hybrid and Multicloud

Thu, 04 Dec 2025 00:00:00 +1100

If an Azure Landing Zone is your perfectly dialled-in espresso shot, then extending it to hybrid and multicloud environments is like adding a splash of milk and foam—smooth integration, but balance is everything.
Enterprises rarely live in a single-cloud world anymore, and Microsoft’s Azure Landing Zone (ALZ) blueprint is evolving to embrace this complexity with hybrid and multicloud patterns.

As cloud estates span data centres, AWS, and private clusters, it’s no longer enough for ALZ design areas to stop at the Azure boundary. In this post, we’ll unpack how to seamlessly extend the ALZ approach beyond Azure—while keeping consistent governance, security, and observability in the mix, and respecting the special conditions of Sovereign Landing Zones (SLZs).

What is Hybrid and Multicloud Extension of an ALZ?

Hybrid and multicloud extension refers to applying Azure Landing Zone design principles and controls to resources that sit outside Azure, such as on-premises servers or workloads hosted in AWS or Google Cloud.

The Azure Landing Zone concept—rooted in the Cloud Adoption Framework (CAF)—includes governance, operations, networking, and identity. Extending these patterns ensures non‑Azure resources are equally governed, monitored, and secured under a unified control plane.

Microsoft achieves this through services such as:

Azure Arc – Extends Azure Resource Manager (ARM) to physical or virtual resources hosted anywhere.
Microsoft Defender for Cloud connectors – Bring AWS and GCP accounts under unified security posture management.
Microsoft Entra ID – Provides consistent identity and Conditional Access across platforms.
Automation & DevOps Pipelines – Landing Zone accelerators built with Bicep or Terraform can enforce governance continuously.
Sovereign Landing Zones (SLZs) – Variants of ALZ optimised for compliance, regulatory restrictions, and regional data sovereignty, particularly relevant for defence and public organisations.

How It Works

Extending ALZ beyond Azure involves connecting external resources to the Azure control plane via Azure Arc, applying existing management groups, policies, and role assignments to them, and orchestrating deployments through automation pipelines.

Architecture Overview

flowchart TD subgraph Azure A[Management Group Hierarchy] B["Policy & RBAC via Entra ID / PIM"] C["Azure Monitor / Log Analytics / Sentinel"] G["Landing Zone Automation - Bicep Pipelines"] end subgraph External D["Azure Arc-enabled Servers & Clusters"] E["AWS & GCP Accounts via Defender for Cloud Connectors"] F["On-premises Network Fabric"] end A --> B --> C A --> D A --> E D --> F G --> A C -->|"Unified Logs & Metrics"| F

Design Area Alignment

Design Area	Hybrid Extension Pattern
Identity & Access Management	Entra ID federation and PIM extend RBAC. Hybrid staff identities reside in a single tenant or trusted forests.
Resource Organisation	Hybrid assets appear under existing management groups such as `/providers/Microsoft.Management/managementGroups/Contoso-Hybrid`.
Networking	Use Azure Network Manager to link ExpressRoute, VPN, and multicloud peering. Ensure DNS and firewalls support name resolution for Arc and Defender endpoints.
Security & Compliance	Policies and Defender for Cloud baselines enforced across connected cloud providers.
Monitoring	Azure Monitor and Log Analytics centralise observability; Arc collects guest and container telemetry.
Automation & DevOps	ALZ Accelerator Bicep modules or Terraform templates manage deployments uniformly across environments.

Real‑World Impact

For most enterprise environments, hybrid isn’t a transition—it’s the new default.

Take a state government agency required to meet local data residency and IRAP compliance. They operate on Azure Australia Central, host sensitive datasets on an on‑premises secure enclave, and leverage AWS for public‑facing digital services.
By enabling Azure Arc, Defender multicloud connectors, and unified Entra ID, the agency enforces consistent governance through a single ALZ hierarchy while maintaining jurisdictional controls per SLZ mandates.

Their compliance posture—aligned with Australian Government ISM and DTA Hosting Certification—is visible in one place, enabling continuous compliance without separate operational silos.

Implementation Examples

Azure Portal: High-Level Steps

In Azure Portal, go to Azure Arc → Servers → Add.
Download and install the Arc agent on any non‑Azure machine.
The resource appears in your subscription under the correct management group.
Enable Defender for Servers or Defender for Containers for extended protection.
Apply Azure Policy guest configuration for ongoing compliance.
Deploy automation pipelines (e.g., Bicep via GitHub Actions) to enforce governance continuously.

Bicep Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


param arcServerName string
param location string = resourceGroup().location
param policyAssignmentName string
param policyDefinitionId string
param policyScope string = resourceGroup().id

resource arcServer 'Microsoft.HybridCompute/machines@2022-08-11' = {
 name: arcServerName
 location: location
 properties: {
 osName: 'Linux'
 osVersion: 'Ubuntu20.04'
 }
}

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
 name: policyAssignmentName
 properties: {
 displayName: 'Arc Server Security Baseline'
 policyDefinitionId: policyDefinitionId
 scope: policyScope
 }
}

module platformAutomation '../modules/alz-pipelines.bicep' = {
 name: 'deploy-pipelines'
 params: {
 mgScope: subscription().id
 }
}

This sample ties Arc registration and policy assignment together, then references a reusable ALZ automation module for deployment pipelines.

Sovereign Cloud Integration Examples

For Sovereign Landing Zones, especially in Azure Australia Central, Azure Government, or Azure China, there are additional steps:

Use private or restricted connectivity for all Arc agent communications—via Private Link or approved egress proxies.
Deploy monitoring and Defender instances within each sovereign region to maintain data residency.
Configure regional Log Analytics workspaces and local Sentinel instances to avoid telemetry export breaches.
Align resource tagging and policy definitions with your compliance framework—e.g., IRAP, ISO 27001, or Essential Eight maturity goals.

Gotchas & Edge Cases

Latency and agent dependencies: Arc‑enabled servers need outbound connectivity to regional Azure endpoints—tricky in sovereign or air‑gapped environments.
RBAC and PIM gaps: Temporary elevation or mismatched role definitions can break automation. Sync identity definitions and enforce PIM controls.
Disconnected or restricted SLZs: Some configuration scripts assume public Azure endpoints; pre‑validate management URLs for sovereign clouds.
Policy drift: Multicloud connectors may introduce lag in policy or Defender posture reporting.
Automation scope: When deploying landing zones via pipelines, ensure identity permissions span hybrid management groups and subscriptions.

Best Practices

Centralise policy at management group level – Create a contoso-hybrid node under your ALZ hierarchy for hybrid assets.
Enforce least privilege through Entra ID and PIM, including workload identities for automation accounts.
Use Arc for Servers, Kubernetes, and SQL to maximise telemetry and control plane reach.
Deploy landing zone accelerators via CI/CD pipelines, using the official ALZ Bicep modules or Terraform equivalents.
Segment sovereign workloads into their own subscriptions, mapped to regional constraints.
Operate monitoring regionally – Keep logs and data within sovereign or regulated regions.
Continuously review Defender connectors and APIs to align with provider updates.

🍺

Brewed Insight: A great flat white is all about balance—so is hybrid governance.
When you extend Azure Landing Zones into hybrid and sovereign clouds, think of it less as expanding control and more as achieving operational harmony: consistent identity, policy, and assurance everywhere your workloads live.

Learn More

From Zero to Hero: The Journey to Microsoft MVP

Wed, 03 Dec 2025 00:00:00 +1100

One Month Later

It’s been a month since that email landed — the one that made every late night, every draft blog, and every community chat feel worthwhile. I’d officially joined the ranks of the Microsoft MVPs.

For nearly two years, that goal hovered quietly in the background. Not as a badge of validation, but as a symbol of growth, proof that passion and persistence in the community could translate into meaningful impact.

Inspiration Close to Home

My motivation came from seeing others do what I aspired to do. Working alongside Australian MVPs and local content creators showed me what genuine community engagement looked like it’s collaboration over competition, learning over ego.

They weren’t chasing recognition; they were sharing because they loved what they did. That energy was contagious, and it helped me find my own rhythm.

A Look at the Numbers

The Microsoft MVP community might seem global and vast with around 3900 members around the world, but drill down to Australia where is only 122 (thats ~3.12%) current MVP’s whilst unsurprising for sum what it does suggest that a tight-knit group or people are making a significant local impact.

MVPs in Australia by Category

Category	Approx. Count
Developer Technology	5
M365	28
Business Applications	20
Data Platform	13
Azure AI Foundry	14
Azure	22
Internet of Things	1
Windows Devices	7
Security	14
Cloud and Data Management	1
Windows Development	1
Total	122

You can easily see where Australia’s MVP strength lies — M365 and Azure lead the way, reflecting how deeply those platforms run across local enterprises.

MVPs in Australia by State/Territory

State / Territory	Approx. Count
New South Wales (NSW)	39
Australian Capital Territory (ACT)	2
Queensland (QLD)	26
South Australia (SA)	7
Victoria (VIC)	39
Western Australia (WA)	8
Total	122

I call NSW home and with around 8 Azure MVPs in the state

Writing with Purpose

For me, it all started with writing. Sharing what I learnt about Azure networking, infrastructure, and security wasn’t just about documenting my work it has become how I learned best.

Consistency was the real differentiator. I didn’t write because I had free time; I made time because I wanted to contribute. Even when writer’s block kicked in, even when posts didn’t land perfectly I showed up again the next week.

That’s what slowly turned effort into opportunity.

Burnout, Block, and Brewing Through It

There were definitely low points. Burnout crept in. Writer’s block hit hard. Some weeks I’d question whether the effort even mattered.

If you’re creating content or contributing to the community, a few lessons I learnt the hard way:

Consistency ≠ relentlessness. You can take breaks. Sustainability beats speed.
Batch your creativity. When you’re in the zone, create more than you need.
Connect with others. Community thrives on collaboration, not just contributions.

Some of my best ideas came after a pause, not during the grind. Much like coffee — sometimes you need to let it brew.

Supported by Community

I owe so much to the people who encouraged me when they didn’t have to those who read early drafts, shared posts, invited me to speak, or simply said, “keep going”.

Behind every MVP announcement is an invisible network of encouragers and motivators. My success is as much theirs as it is mine.

Understanding the MVP Application Process

Since going through this process myself I have had others ask around how someone becomes an MVP, so let’s break it down.

To be considered for the Microsoft MVP program:

You must be nominated — either by a current MVP or a Microsoft Full-Time Employee (FTE).
You need to provide evidence of your community reach: blogging, public speaking, mentoring, open-source contributions, or any content that helps others.
Your community work must be independent of your paid employment. For example, I regularly speak at webinars hosted by cubesys, but those can’t count toward my community metrics.
Consistency matters. Doing one talk or a couple of posts a year won’t cut it. You need to show sustained engagement.
Stay in your lane. Pick the category you genuinely live and breathe. I focused on Azure, it wouldn’t make sense for me to apply under “Software Development” when that’s not my craft.
Find a mentor. Someone already in the program can be invaluable. They’ll have tips, advice, and nuances you won’t find written anywhere.

The process isn’t designed to gatekeep, it’s designed to recognise authenticity. Microsoft wants people who build community impact, not just technical trivia.

Encouraging Others to Chase Their Goals

If the MVP journey isn’t your thing, that’s okay. The real message here is to pursue what excites you.
Maybe that’s an AWS Hero, a Google Cloud Champion Innovator, or a VMware vExpert. Each has its own flavour, but they all celebrate the same principle: sharing knowledge and growing your community.

If you’re passionate about cloud, security, AI, or open source — start creating, start engaging, start small. You don’t need permission to make an impact.

As I learnt, the most meaningful journeys don’t start with “how do I get recognised?” — they start with “what can I share today that might help someone else?”

The Journey Doesn’t End Here

Becoming an MVP isn’t where it ends, it’s just a checkpoint.
There’s more to learn, more to build, and more to give back.

Now that I’ve earned the badge, the goal has shifted to helping others earn theirs, mentoring new contributors, and keeping that same curiosity that started all this in the first place.

🍺

Brewed Insight: Community recognition is brewed from authenticity, consistency, and curiosity.
Awards are fleeting however the impact you make by helping others lasts far longer.

Learn More

Brewing the Latest Azure Landing Zone – Security Operations and Threat Protection

Tue, 02 Dec 2025 00:00:00 +1100

You’ve built your landing zone, hardened the edges, and enabled controls—congratulations! But as every seasoned security engineer knows, configuration is only half the battle. Now comes the grind: operationalising your defences. Security operations in Azure isn’t about panic-driven dashboards; it’s about creating a steady rhythm where detection, investigation, and response hum together—like an espresso machine firing on precise pressure and timing.

In this post, we explore how to bring your Secure Landing Zone (SLZ) to life—turning design principles into active defence through Defender for Cloud, Microsoft Sentinel, and well‑orchestrated response automation.

☁️ What is Security Operations in the Azure Landing Zone?

Within the Microsoft Cloud Adoption Framework (CAF), “Security” and “Operations” are distinct but tightly woven design areas. The Security Operations & Threat Protection pillar of a landing zone focuses on three operational layers:

Detection & Prevention – Using Azure-native telemetry and analytic capabilities to identify threats in real time.
Response & Recovery – Orchestrating workflows to minimise response time.
Continuous Improvement – Leveraging incident learnings to refine detections, policies, and processes.

The Secure Landing Zone (SLZ) expands on the ALZ baseline by pre‑configuring Defender for Cloud, Sentinel, and Azure Policy for consistent management across tenants and environments.

For Microsoft Sovereign Landing Zones, this foundation adheres to regional compliance and data residency rules—ensuring operational tooling and telemetry remain within the sovereign boundary.

⚙️ How It Works

Core Azure services and design patterns supporting security operations include:

Microsoft Defender for Cloud – Posture management and workload protection across hybrid resources.
Microsoft Sentinel – Cloud-native SIEM/SOAR providing analytics, automation, and incident correlation.
Azure Monitor / Log Analytics – The telemetry backbone that feeds both proactive (Defender) and reactive (Sentinel) insights.
Logic Apps / Automation Accounts – Enable incident response playbooks and triage workflows.
Azure Policy & Initiative Assignments – Automate deployment and configuration of Defender and Sentinel across landing zones.

Control Plane Alignment

Operational tooling aligns with your CAF management group hierarchy:

graph TD A[Root Management Group] --> B[Platform MG] B --> C[Management & Monitoring Subscription] B --> D[Connectivity Subscription] B --> E[Workload Subscriptions] C --> F[Microsoft Sentinel Workspace] E --> G[Resource Groups - Workloads] E --> H[Defender for Cloud Initiative]

Control Flow Summary

Defender for Cloud continuously evaluates resources and raises alerts.
Alerts and security recommendations stream into Sentinel via connectors.
Sentinel analytics rules correlate and prioritise incidents.
Response playbooks (Logic Apps) are triggered automatically or manually.
Insights feed governance reporting and inform Azure Policy updates.

🏢 Real-World Impact

A financial organisation deploying workloads across multiple ALZ instances found that decentralised monitoring led to inconsistent incident handling. By introducing a centralised Sentinel & Defender deployment, they:

Unified threat monitoring under a single pane of glass.
Normalised incident templates and playbooks.
Reduced incident response time by more than 40 %.
Simplified compliance reporting across jurisdictions (including sovereign growth regions).

Security operations maturity thus became an enabler of scale—not just a safeguard.

🧭 Implementation Examples

Azure Portal Steps

Enable Defender for Cloud at the management group level.
Deploy Sentinel in a central monitoring subscription linked to a Log Analytics workspace.
Connect Data Sources:
- Azure AD Sign‑In Logs
- Defender for Cloud Alerts
- Microsoft 365 and Entra Audit Logs
Create Automation Playbooks for incident response.
Tune Analytics Rules to fit your environment—start with the Microsoft Security content pack and customise thresholds.

Bicep Example – Sentinel and Defender Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
 name: 'lz-secops-law'
 location: resourceGroup().location
 sku: { name: 'PerGB2018' }
 retentionInDays: 90
}

resource sentinel 'Microsoft.SecurityInsights/onboardingStates@2023-02-01-preview' = {
 name: 'default'
 properties: {
 source: 'AzureSentinel'
 workspaceResourceId: logAnalytics.id
 }
}

resource defenderVMs 'Microsoft.Security/pricings@2023-01-01' = {
 name: 'VirtualMachines'
 properties: { pricingTier: 'Standard' }
}

ℹ️

Adjust Defender plans and workspace retention for compliance or sovereign requirements

⚠️ Gotchas & Edge Cases

Cross‑tenant ingestion: Verify Sentinel workspaces can ingest logs from delegated tenants with proper permissions (reader/contributor roles).
Duplicate alerts: When connecting Defender and Sentinel, disable redundant analytics templates to avoid noisy false positives.
Sovereign Cloud gaps: Some connectors (e.g., M365 or AWS) may not be available—check sovereign-specific documentation.
Role design: Use least‑privilege RBAC—grant only Sentinel Responder or Reader roles to analysts, not subscription‑wide Owner rights.
Scale limits: At high ingestion volumes (>2 TB/day), consider data partitioning or multiple Sentinel workspaces for performance management.

✅ Best Practices

Deploy centralised Sentinel and Defender instances under the Platform / Management & Monitoring subscription.
Use Azure Policy initiatives to enforce Defender plan enablement globally.
Implement Logic App playbooks with approval workflows for high‑impact actions.
Regularly review analytic rule efficacy—disable low‑fidelity detections.
Correlate security data with cost and governance metrics to validate operational ROI.
Map all incidents and controls against the Microsoft Cloud Security Benchmark (MCSB).
For sovereign landing zones, validate region‑specific compliance mappings and restrict cross‑region log export.

🍺

Brewed Insight: Security operations aren’t a one‑time pour—they’re a continuous blend of policy, detection, and human insight. The caffeine kick comes not from how many alerts you generate, but from how effectively you respond and refine.

🔗 Learn More

Brewing the Latest Azure Landing Zone – Automating Your Platform

Thu, 27 Nov 2025 00:00:00 +1100

Think of your Azure Landing Zone (ALZ) like a perfectly brewed flat white. You can handcraft each shot—carefully spinning up management groups, policies, and subscriptions—or you can automate the process with precision, ensuring each brew (deployment) tastes just as intended.

Automation is where mature cloud environments lift from repeatable to reliable. In this post, we’re taking that next step: automating your platform layer using Infrastructure as Code (IaC) and modern CI/CD practices with Azure DevOps and GitHub Actions.

What is Landing Zone Automation?

Landing zone automation turns the conceptual Azure architecture from the Cloud Adoption Framework (CAF) into deployable, consistent reality.

It’s about codifying the platform foundation—management groups, policies, networks, role assignments, and more—so your entire environment can be replicated, validated, and governed repeatably.

Whether you’re deploying Microsoft’s standard ALZ composition or the Sovereign Landing Zone (SLZ) for government and regulated industries, automation ensures:

Consistent structure across tenants and subscriptions
Version-controlled platform definitions
Governance and compliance baked into the deployment pipeline
Smooth integration with organisational CI/CD tooling

How It Works

At the heart of automated landing zones sits a hierarchy of IaC definitions and orchestrations:

1. Core IaC – Bicep Evolution

Bicep has now matured beyond a deployment language—it’s the clear path forward from ARM templates.
With ALZ modules defined in Bicep, engineers can:

Parameterise management group hierarchies
Configure resource consistency across environments
Simplify updates and version pinning through Azure Container Registry (ACR)-hosted modules

The latest ALZ accelerator leverages reusable Bicep modules organised by design area—Identity, Network, Governance, Management, and Security.

2. Deployment Orchestration

Infrastructure deployment happens through:

Bootstrap scripts (main.bicep orchestrators or PowerShell wrappers)
Azure DevOps pipelines or GitHub Actions for environment rollout
Separate parameter files (e.g., dev, test, prod, sovereign) for scalable multi‑environment management

3. Control Plane Integration

Each run authenticates via a managed identity or service principal with least‑privilege RBAC, deploying to the control plane (management groups, policy assignments, subscriptions).
The pipeline enforces drift detection through outputs from what-if operations before applying changes.

flowchart LR A[Git Repository] --> B[Pipeline Trigger] B --> C{Environment?} C -->|Prod| D[Deploy Bicep modules to MG hierarchy] C -->|Test| E[Deploy to sandbox subscriptions] D --> F[Policy & Blueprint Assignment] E --> F F --> G["Post-deployment validation"] G --> H["Success Notification / Azure Monitor Logs"]

Sovereign Landing Zone Automation

For regulated workloads, the Sovereign Landing Zone (SLZ) introduces additional validation layers and compliance automation.

SLZ deployments use the same core ALZ Bicep modules but add governance and security overlays specific to sovereign or isolated cloud environments.

Key components to automate include:

Deployment to sovereign‑specific tenants with restricted Azure AD endpoints
Policy and Initiative Definitions sourced from the SLZ GitHub repository
Compliance blueprint outputs registered as artefacts for audit traceability
Approval gates and manual interventions where government regulations require validation
Separation of parameter sets per compliance classification (e.g. Standard, Protected, Secret System)

This layered model ensures sovereign deployments remain CAF‑aligned while adhering to national compliance and residency requirements.

Real‑World Impact

Let’s take a common enterprise example:
A national healthcare organisation managing both standard and sovereign tenants across regions.

With automated landing zones, they can:

Provision new regulated workloads automatically through the Sovereign Landing Zone blueprint
Apply the same guardrails, RBAC assignments, and network controls to every deployment
Satisfy compliance audits via Git version history of policy assignments and configurations
Maintain consistent operations pipelines across both public and sovereign Azure clouds

This removes human error from foundational design and shifts governance to “code as policy”.

Implementation Examples

Deploying via the Azure Portal or CLI

For teams just beginning to automate, you can start with Azure CLI or PowerShell to deploy the ALZ accelerator:

1
2
3
4
5


az deployment sub create \
 --name platformBootstrap \
 --location australiaeast \
 --template-file main.bicep \
 --parameters @parameters.prod.json

Using Bicep – Example Snippet

Below is a simplified snippet showing an automated management group structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


param rootMgId string = 'contoso-root'
param landingZoneParent string = 'platform'

module mgNetwork 'modules/mg.bicep' = {
 name: 'mgNetwork'
 params: {
 displayName: 'Network'
 parentId: rootMgId
 }
}

module mgSecurity 'modules/mg.bicep' = {
 name: 'mgSecurity'
 params: {
 displayName: 'Security'
 parentId: rootMgId
 }
}

output mgIds object = {
 network: mgNetwork.outputs.id
 security: mgSecurity.outputs.id
}

Supplementary Module Files

Each module encapsulates a discrete design area—aligning with the ALZ approach of modular, reusable components.

📂 `modules/mg.bicep`

Creates or updates a management group and outputs its ID.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


param displayName string
param parentId string

resource mg 'Microsoft.Management/managementGroups@2021-04-01' = {
 name: uniqueString(displayName)
 properties: {
 displayName: displayName
 parent: {
 id: tenantResourceId('Microsoft.Management/managementGroups', parentId)
 }
 }
}

output id string = mg.id

📂 `modules/policyAssignment.bicep`

Assigns a built‑in or custom policy or initiative to the management group level.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


param policyDefinitionId string
param displayName string
param scope string
param parameters object = {}

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2021-06-01' = {
 name: uniqueString(displayName)
 properties: {
 displayName: displayName
 policyDefinitionId: policyDefinitionId
 scope: scope
 parameters: parameters
 enforcementMode: 'Default'
 }
}

output assignmentId string = policyAssignment.id

📂 `modules/roleAssignment.bicep`

Grants a role definition to a service principal, group, or managed identity.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


param principalId string
param roleDefinitionId string
param scope string

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
 name: guid(principalId, roleDefinitionId, scope)
 properties: {
 principalId: principalId
 roleDefinitionId: roleDefinitionId
 scope: scope
 }
}

📂 `modules/networking/vnet.bicep`

Defines a basic virtual network with multiple subnets.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


param vnetName string
param location string
param addressSpace string = '10.0.0.0/16'
param subnets array = [
 {
 name: 'default'
 prefix: '10.0.0.0/24'
 }
]

resource vnet 'Microsoft.Network/virtualNetworks@2023-04-01' = {
 name: vnetName
 location: location
 properties: {
 addressSpace: {
 addressPrefixes: [ addressSpace ]
 }
 subnets: [for subnet in subnets: {
 name: subnet.name
 properties: {
 addressPrefix: subnet.prefix
 }
 }]
 }
}

output vnetId string = vnet.id

Bicep File Structure Example

A typical repository layout for an automated landing zone looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


/alz-platform/
│
├── main.bicep # Root orchestrator for entire platform
├── modules/ # Reusable modules by design area
│ ├── mg.bicep # Management group creation
│ ├── policyAssignment.bicep # Azure Policy or Initiative deployment
│ ├── roleAssignment.bicep # RBAC bindings
│ ├── networking/
│ │ ├── vnet.bicep
│ │ └── firewall.bicep
│ └── identity/
│ └── managedIdentity.bicep
│
├── parameters/
│ ├── prod.parameters.json
│ ├── test.parameters.json
│ └── sovereign.parameters.json
│
└── pipelines/
 ├── azure-pipelines.yml # Azure DevOps pipeline definition
 └── deploy-alz.yml # GitHub Actions workflow

Each folder represents a deployable component, enabling modular rollouts and granular version control.
This layout scales naturally for multi‑environment and multi‑tenant SLZ scenarios where the sovereign parameters and policy baselines differ.

Gotchas & Edge Cases

A few real‑world kinks to watch out for:

Management group drift: Ensure pipelines perform what-if prior to deployments to catch unexpected manual changes.
Policy replication lag: Azure Policy assignments can take minutes to propagate; build delay logic or retry policies into orchestrations.
Sovereign Cloud API differences: Sovereign regions (e.g., Azure Government) may have limited support for preview resource providers—always validate pipeline dependencies in each environment.
Permissions & scope: The service connection must have Management Group Contributor and Policy Contributor roles at the root management group for full control-plane deployments.
Parameter reuse drift: Reusing *.parameters.json files across dissimilar tenants may cause mismatched IDs—keep parameter sets per environment.

Best Practices

Use Bicep modules with version pinning to avoid breaking changes from upstream ALZ module updates.
Treat the pipeline as the source of truth, never the portal—manual changes create drift.
Apply policy assignments and role definitions within IaC, not post-provisioning.
Structure repositories by design area or environment, depending on operating model.
Incorporate Azure Policy compliance scans or what-if previews into every pull request.
Separate parameter files for sovereign, regulatory, and standard environments.
Integrate approval gates in DevOps or GitHub to replicate SLZ-compliant change control.

🍺

Brewed Insight: Automation isn’t just about saving clicks; it’s about embedding your governance model into code and culture. Once your landing zone can deploy itself—public or sovereign cloud alike—your platform becomes the recipe, not the experiment.

Learn More

Brewing the Latest Azure Landing Zone – Monitoring, Insights, and Operational Maturity

Tue, 25 Nov 2025 00:00:00 +1100

Imagine running a busy café with no visibility into stock, brewing temperature, or order flow you’d end up guessing where the bottlenecks are. Azure environments aren’t that different. Without proper monitoring and operational insight, you’re flying blind across your landing zones.

As enterprises adopt the new Azure Landing Zone (ALZ) architecture, observability becomes more than a convenience, it’s a foundation for security, resilience, and compliance. This post explores how the modern ALZ and Secure Landing Zone (SLZ) patterns enable full‑stack visibility, from management groups to workload telemetry, and how new Cloud Adoption Framework (CAF) guidance continues to evolve the story for both global and sovereign deployments.

What is Monitoring & Operational Maturity in the ALZ Context?

Azure Landing Zones define a set of design areas — governance, identity, networking, resource organisation, and monitoring. The Monitoring and Insights design area underpins everything else in the ALZ model, ensuring consistent telemetry and response capability across all environments.

Key objectives include:

Centralised telemetry and diagnostics for platform and workload components.
Alignment with Microsoft Defender for Cloud and Microsoft Sentinel for proactive threat detection.
Building operational maturity through alert tuning, automation, and policy‑based guardrails.
Supporting sovereign and regulated environments through strict data‑residency boundaries.

In short, monitoring isn’t just data collection — it’s the barista’s dashboard of dials and indicators keeping your Azure brew consistent and under control.

How It Works

At its core, observability in ALZ is about collecting, correlating, and responding. Azure provides the ingredients — you architect how they blend.

Core Layers of Monitoring

Platform Layer (Landing Zone & Management Groups)
- Activity logs and policy compliance at the tenant and management group level.
- Diagnostic settings for core services (Resource Manager, Policy, Security Center).
- Centralised Log Analytics workspaces per environment or region.
- Governance integration via CAF Monitor & Manage design area templates.
Workload Layer (Application & Data)
- Application Insights, container telemetry, database metrics, and workload‑specific logs.
- Data Collection Rules (DCRs) via Azure Monitor Agent (AMA) for VM and container telemetry.
Security Layer (Sentinel & Defender Plans)
- Microsoft Sentinel fuses threat and operational data from multiple sources.
- Defender for Cloud enforces continuous assessment and workload protection.
Operations & Integration Layer
- Azure Automation, Logic Apps, and Event Grid for reactive and proactive operations.
- ServiceNow or ITSM connectors for unified incident lifecycle management.

Control Plane Relationships

Below is a simplified view of how these layers connect through management and resource hierarchies:

flowchart TD Tenant["Tenant Root Group"] MG1["Management Group: Platform"] MG2["Management Group: Workloads"] Sub1["Subscription: Connectivity & Security"] Sub2["Subscription: Landing Zone"] LA["Log Analytics Workspace"] Sentinel["Microsoft Sentinel"] Defender["Defender for Cloud"] RG["Resource Groups"] Tenant --> MG1 --> Sub1 Tenant --> MG2 --> Sub2 Sub1 --> LA LA --> Sentinel LA --> Defender Sub2 --> RG RG --> |Diagnostic + Metric Data| LA

This topology serves as the backbone of platform‑wide observability — scalable and repeatable across multiple landing zones.

Real‑World Impact

In a typical enterprise rollout:

Central IT manages a shared monitoring workspace and Sentinel instance in the platform management group.
Business units deploy their own Application Insights instances for line‑of‑business workloads.
Security operations correlate activities across Defender plans, policy compliance, and workload signals.
Troubleshooting shifts from guesswork to traceable, data‑driven investigation.

Sovereign‑Specific Observability Design Considerations

Microsoft’s Sovereign Landing Zone (SLZ) reference architecture introduces additional observability controls and compliance‑driven design practices, including:

Data Egress Restrictions – All diagnostic and telemetry data must remain in the local jurisdiction. Use region‑local Log Analytics and Sentinel endpoints only.
Identity & Access Separation – Split monitoring permissions between operators and compliance staff using Privileged Access Workstations (PAWs) and Just‑In‑Time (JIT) access through Privileged Identity Management (PIM).
Regional Sovereignty Guards – Enforce workspace creation within approved sovereign regions via Azure Policy and the CAF Monitor & Manage landing zone accelerator.
Sovereign Data Scopes in Defender for Cloud – Use region‑scoped threat protection plans and local intelligence feeds.
Multi‑Ring Visibility via Lighthouse – Aggregate insights across sovereign “rings” through Azure Lighthouse, maintaining read‑only, cross‑region visibility without data egress.

These additions are essential when applying ALZ patterns to regulated or government workloads hosted in sovereign clouds such as Australia Central, Norway East, or US Gov.

Implementation Examples

Azure Portal Steps (High Level)

Deploy a Log Analytics Workspace in the designated monitoring subscription.
Configure Diagnostic Settings for key platforms (Policy, Key Vault, NSG, Activity Logs).
Enable Microsoft Defender for Cloud and align protection plans with CAF Monitor & Manage guidance.
Connect Microsoft Sentinel to the workspace.
Apply Data Collection Rules (DCRs) to route VM metrics through AMA.
Add automated responses and escalation through Logic Apps or Azure Automation Runbooks.

Example Bicep Snippet

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2023-09-01' = {
 name: 'law-monitoring-platform'
 location: resourceGroup().location
 sku: {
 name: 'PerGB2018'
 }
 retentionInDays: 90
}

resource diagnosticSettings 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
 name: 'send-activity-logs'
 scope: subscription()
 properties: {
 workspaceId: logAnalytics.id
 logs: [
 {
 category: 'Administrative'
 enabled: true
 }
 {
 category: 'Policy'
 enabled: true
 }
 ]
 }
}

This Bicep snippet centralises subscription‑level activity logs. For SLZ implementations, ensure the workspace’s region aligns with data residency constraints and that cross‑region ingestion is blocked.

Gotchas & Edge Cases

Duplicate Diagnostic Streams: Avoid redundant diagnostic settings across policies — they can double ingestion costs.
Workspace Misplacement: Check Log Analytics and Sentinel regions for compliance; this is critical in sovereign implementations.
Alert Fatigue: Default Sentinel content packs are noisy. Phase in analytics rules gradually.
Multi‑Cloud Integration: Consider data boundaries before integrating with third‑party SIEMs.
Cross‑Tenant Complexity: For multi‑ring SLZ models, use Azure Lighthouse to provide delegated access without compromising sovereignty.

Best Practices

Centralise baseline telemetry in a dedicated monitoring or management subscription.
Align resource locations and retention with regional compliance mandates.
Enable Defender for Cloud early in the rollout to automatically evaluate resource security posture.
Leverage CAF Monitor & Manage accelerator for standardised baselines across tenants.
Automate configuration drift detection via Azure Policy and DINE scripts.
Regularly tune alert rules and analytics in Sentinel to reduce noise.
Document and test incident response playbooks across both ALZ and SLZ environments.

🍺

Brewed Insight: Operational maturity isn’t achieved with dashboards — it’s cultivated through continuous tuning, feedback, and disciplined automation. Observability is your infrastructure’s sensory system. Get it right, and every signal — whether from Sydney or a sovereign enclave — pours clean and consistent like a perfectly calibrated espresso.

Learn More

Brewing the Latest Azure Landing Zone – Policy, Governance and Compliance at Scale

Thu, 20 Nov 2025 00:00:00 +1100

Any seasoned barista will tell you that consistency is the secret ingredient. The same holds true for your cloud estate — it’s no good if every subscription ends up with a slightly different flavour. Governance in Azure Landing Zones (ALZ) ensures every cup (or workload) comes out consistent, auditable, and within your compliance recipe.

This post explores how Azure Policy, security baselines, and Microsoft’s Sovereign Landing Zone work together to create policy‑driven guardrails. We’ll look at how automation enforces consistency at scale and how those controls transfer neatly from an Azure Landing Zone (ALZ) to a Secure Landing Zone (SLZ).

☁️ What is Policy‑Driven Governance?

Policy‑driven governance is the backbone of any ALZ. It forms the control plane, enforcing compliance, tagging standards, cost management, and security configurations across management groups.

At the heart of this model is Azure Policy, which uses declarative JSON definitions to apply rules and standards across your environment. These can enforce mandatory compliance (deny actions) or informative compliance (audit only).

Microsoft’s Cloud Adoption Framework (CAF) and Azure Landing Zone Accelerators provide foundational policy sets that align with key governance disciplines:

Resource Consistency: Standard naming, tagging, and region restrictions
Security & Compliance: Enforce Defender plans, encryption, or private networking
Operational Governance: Ensure diagnostic and monitoring settings are applied by default
Data Sovereignty: Especially critical in Sovereign Landing Zone (SLZ) contexts

⚙️ How It Works

Azure Policy enforcement operates at multiple levels in your management group hierarchy, creating a cascading and inheritable model for governance.

Updated Example – ALZ Management Group Structure

graph TD A[Root Management Group] --> B[Platform MG] A --> C[Workloads MG] B --> D[Identity MG] B --> E[Management MG] B --> F[Connectivity MG] C --> G[App Workloads MG] G --> H[Subscription Level Resources]

Policies and initiatives are typically assigned at the management group level:

Definitions – JSON policy logic describing compliance rules
Initiatives – Bundled sets of policies for a common intent (e.g. Security Baseline)
Assignments – Bind the definition or initiative to a specific scope
Remediation – Automated correction of non‑compliant resources

A practical example of this is constraining Private DNS Zone creation. By assigning a policy that restricts DNS resource providers to only the Connectivity Management Group, we ensure network services remain centralised and consistent. This prevents application teams from spinning up ad‑hoc DNS zones that undermine cross‑environment name resolution — a subtle guardrail that pays big dividends later.

For Sovereign Landing Zones, these initiatives also incorporate regional membership, encryption requirements, and connectivity isolation patterns aligned with frameworks like IRAP (Australia) or FedRAMP (US).

🌏 Real‑World Impact

In large organisations, subscriptions proliferate quickly and with good intent — but without policy control, drift and inconsistency take hold fast.

Deploying ALZ policy assignments upfront ensures governance remains proactive. For example:

Scenario: You need to ensure Private DNS Zones live only in the central Connectivity Zone.
Outcome: The policy denies or remediates deployments of Microsoft.Network/privateDnsZones outside approved management groups — keeping name resolution consistent across the enterprise fabric.
Scenario: The security team mandates encryption‑at‑rest for all storage.
Outcome: A centrally enforced policy denies creation of unencrypted storage accounts, avoiding drift before it happens.
Scenario: A financial institution operating under Australian data sovereignty constraints.
Outcome: Using the Microsoft Sovereign Landing Zone baseline automatically ensures data only resides in the Australia East/Southeast region pair, maintaining integrity and compliance with IRAP standards.

When these controls are defined early and baked into your deployment pipelines, the platform team spends less time firefighting and more time improving developer experience.

💻 Implementation Examples

Deploy via Azure Portal

From the Azure Policy blade:

Navigate to Definitions → Policy Initiatives (set)
Select Assign Initiative at the top‑level management group
Choose the ALZ Policy Set (for example, AzureLandingZone-PolicySet-v3) or a Sovereign variant such as SovereignLandingZone-IRAP
Configure relevant parameters like allowedLocations, connectivityManagementGroupId, or logWorkspaceId

Select Review + Create to assign — Azure will begin evaluating and remediating resources automatically.

Deploy via Bicep

Here’s a minimal example for assigning a security or governance initiative:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


@description('Management group name for the policy assignment')
param mgName string = 'platform-connectivity'

@description('Policy initiative ID')
param initiativeId string = '/providers/Microsoft.Authorization/policySetDefinitions/AzureLandingZone-Connectivity-v3'

@description('Assignment display name')
param assignmentName string = 'Connectivity-Guardrails'

resource policyAssignment 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
 name: assignmentName
 scope: tenantResourceId('Microsoft.Management/managementGroups', mgName)
 properties: {
 displayName: 'ALZ Connectivity Guardrails'
 policyDefinitionId: initiativeId
 parameters: {
 connectivityMG: {
 value: mgName
 }
 }
 enforcementMode: 'Default'
 }
 identity: {
 type: 'SystemAssigned'
 }
}

This initiative enforces connectivity‑scope controls — such as location restrictions, DNS zone centralisation, and mandatory diagnostic settings — across all workload subscriptions downstream of the connectivity management group.

⚠️ Gotchas & Edge Cases

Timing matters: Policies often depend on existing platform resources such as Log Analytics or Defender plans. Deploy connectivity and identity layers first.
Initiative drift: Modifying a single policy definition inside a standard initiative can cause inconsistencies. Always track initiative versions.
Policy assignment identity: System‑assigned managed identities must have proper permissions, particularly for remediation tasks.
Sovereign feature parity: Not all policy aliases are supported in sovereign clouds — validate definitions against your regulatory baseline matrix.

✅ Best Practices

Apply initiatives at management group level, not per subscription, to reduce governance drift.
Use parameterised initiatives for environment‑specific exceptions.
Store your policy definitions and initiatives in source control alongside your IaC modules.
Enable Azure Policy insights for continuous compliance reporting.
Integrate Policy assignments and Security Baselines with Azure Pipelines or GitHub Actions for repeatable governance.
Explicitly restrict resource types like Private DNS Zones to designated management groups or subscriptions.
Extend ALZ guardrails using Sovereign Landing Zone modules if operating in regulated sectors.

🏛️ Extending Governance for SLZ and Regulated Environments

While most Enterprise ALZ deployments share a common governance baseline, Secure and Sovereign Landing Zones (SLZ) introduce additional depth around compliance validation, exemption management, and continuous monitoring.

1. Compliance and Regulatory Mapping
SLZ policies are frequently tied to frameworks such as IRAP (AU), ISO 27001, and NIST 800‑53. Each policy initiative maps to specific control families (identity, networking, audit, data protection). Integrating these mappings into Defender for Cloud’s Regulatory Compliance Dashboard provides automated evidence collection for audit teams.

2. Policy Exemption Governance
Even in regulated environments, exceptions happen — for example, legacy workloads or non‑supported services. SLZ governance patterns encourage time‑bound policy exemptions with recorded business justification, approval tracking, and optional remediation targets. This process can be automated using policy parameters and version control metadata.

3. Enhanced Monitoring and Audit Policies
SLZ reference guides go beyond standard ALZ diagnostics, enforcing activity log forwarding, resource diagnostic settings, and retention standards for key services such as Key Vault, Storage, and Firewalls.
Embedding those as part of your policy assignments (or deploying the Azure Monitor Baseline initiative) closes the observability gap and builds defence‑in‑depth.

Together, these enhancements ensure governance not only enforces configuration but also proves compliance — a must‑have for regulated sectors and government workloads.

🍺

Brewed Insight: Governance isn’t about locking things down — it’s about keeping flavours consistent across every pour. The magic of Azure Policy is that it frees platform teams from manual policing, while giving developers the confidence to innovate safely within the right boundaries.

📚 Learn More

Brewing the Latest Azure Landing Zone – Networking the Modern Enterprise

Tue, 18 Nov 2025 00:00:00 +1100

If the network is the “espresso shot” of your landing zone, then the connectivity model is your barista — it decides how everything gets blended together. Over the last year, Azure networking patterns have had a serious refill. Between Virtual WAN, private endpoints, and platform-owned connectivity, the modern Landing Zone (LZ) and Secure Landing Zone (SLZ) are paving a clearer path for scalable, secure, and consistent enterprise networking.

This post breaks down what’s changed in the Azure Landing Zone (ALZ) reference design, how it integrates with SLZ guidance, and where sovereign deployment models fit in.

Let’s stir it up.

☁️ What Is “Networking the Modern Enterprise”?

In Microsoft’s Cloud Adoption Framework (CAF), network topology and connectivity is one of the eight core design areas for a Landing Zone. It defines how workloads, users, and services communicate — and how governance and security controls flow through that design.

Historically, enterprises built “Connected Landing Zones” where each domain owned its own virtual network. The Platform team provided connectivity through hub-and-spoke topologies. As governance matured and services like Azure Virtual WAN evolved, Microsoft shifted to the Platform-Owned Connectivity model — a cleaner, scalable, and more secure approach that supports hybrid, multicloud, and sovereign environments.

The latest addition: Sovereign Landing Zone (SLZ) concepts now extend this model for compliant, isolated environments (e.g., financial services, critical infrastructure, or government workloads).

🔌 How It Works

At a high level, modern Azure connectivity now aligns with three design layers:

Platform Connectivity (Core):
A centralised layer that hosts Virtual WAN, route tables, and connectivity policies managed by the platform team.
Landing Zone Networks:
Workload vNets or vWAN hubs connected via private endpoints or secured peering. These zones inherit policies and connectivity from the Platform layer, not peer-to-peer connections.
Secure Landing Zone (SLZ):
Overlays Zero Trust and Defender for Cloud integration on top of the baseline ALZ network model. In many cases, it introduces automated security rulesets and DDoS/Firewall as Code patterns.

In practical terms, traffic flows are now mediated by Virtual WAN hubs, Azure Firewall Premium, and Private Link instead of traditional NVA (Network Virtual Appliance) choke points.

🗺️ Example Architecture

flowchart TD A[On-premises WAN/ExpressRoute] --> B[Virtual WAN Hub] B --> C[Azure Firewall / Security Services] C --> D[Landing Zone vNet 1] C --> E[Landing Zone vNet 2] D --> F[Private Endpoints / PaaS Services] E --> F F --> G[Microsoft Backbone Services]

This structure supports scale-out networking, consistent routing policy enforcement, and integrates neatly with Azure Policy, Defender for Cloud, and Azure Monitor.

🌍 Real‑World Impact

Scenario 1: Hybrid Enterprise with Global Workloads
A financial services customer migrating multiple regional workloads to Azure replaces numerous virtual network peerings with Virtual WAN hubs per geography. Each hub standardises route propagation and central internet egress, cutting operational overhead by 60%.

Scenario 2: Secure Landing Zone for Gov Customers
A government department implementing a Sovereign Landing Zone uses restricted Azure regions and enforces data residency via Virtual WAN secure hubs with isolated Network Security Groups (NSGs). This model passes audit checks for Information Security Manual (ISM) compliance while allowing standardised DevOps pipelines.

🧱 Implementation Examples

Azure Portal – High‑Level Setup Steps

Create a Virtual WAN resource in your platform region.
Add Virtual Hubs for each geography (e.g., AU‑East, SE‑Asia).
Connect VPN/ExpressRoute gateways or on-premises edge routers.
Add hub-to-spoke connections for each Landing Zone vNet.
Configure Azure Firewall Premium, NSGs, and route tables.
Deploy Private Endpoints for platform services (e.g., Storage, SQL).

🧩 Bicep Example – Platform-Owned Connectivity

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


param location string = resourceGroup().location
param vwanName string = 'corp-vwan'
param vhubName string = 'au-east-hub'
param firewallName string = 'corp-fw'

resource vwan 'Microsoft.Network/virtualWans@2023-09-01' = {
 name: vwanName
 location: location
 properties: {
 allowBranchToBranchTraffic: true
 }
}

resource vhub 'Microsoft.Network/virtualHubs@2023-09-01' = {
 name: vhubName
 location: location
 properties: {
 addressPrefix: '10.50.0.0/23'
 virtualWan: {
 id: vwan.id
 }
 }
}

resource azfw 'Microsoft.Network/azureFirewalls@2023-09-01' = {
 name: firewallName
 location: location
 properties: {
 sku: {
 name: 'AZFW_VNet'
 tier: 'Premium'
 }
 threatIntelMode: 'Alert'
 ipConfigurations: [
 {
 name: 'fwConfig'
 properties: {
 subnet: {
 id: resourceId('Microsoft.Network/virtualNetworks/subnets', vhubName, 'AzureFirewallSubnet')
 }
 }
 }
 ]
 }
}

Key Notes

Use Azure Firewall Manager for routing and policy orchestration.
Avoid direct peering between Landing Zones; all traffic should traverse the platform hub.
In SLZ contexts, enforce outbound web traffic inspection and certificate validation.

⚠️ Gotchas & Edge Cases

Private Endpoint Sprawl: Too many PE connections across vNets can cause DNS complexity — consider Private DNS Zones managed centrally.
Cross-region failover: Virtual WAN hubs aren’t automatically resilient across geographies; plan hub failover manually or automate via Bicep.
NVAs in a new world: With Azure Firewall Premium and IDPS features maturing, NVAs should be limited to specific use cases (e.g., vendor-standard inspection or multicloud transit).
Sovereign Regions: SLZ deployments may have resource provider restrictions; confirm service availability before adopting standard ALZ templates.

✅ Best Practices

Adopt Platform-owned Connectivity as the default pattern for enterprise landing zones.
Consolidate policy and tagging strategy across all vNets for traceability and governance alignment.
Use Azure Policy to control where Private DNS Zones can be created — ensuring they reside within the Connectivity (Platform) Zone, not inside workload subscriptions. This keeps name resolution consistent, auditable, and centrally managed.
Deploy Virtual WAN secure hubs with Azure Firewall Premium tier for central egress and Zero Trust enforcement.
Prefer Private Link over service endpoint exposure; eliminate public endpoints altogether.
Manage DNS centrally in the platform layer and link zones to the appropriate spokes via Private DNS zone virtual network links.
Automate hub and spoke deployment using Bicep or Terraform, and avoid ad-hoc peering.
In Sovereign Landing Zones, maintain strict separation between management, workload, and monitoring planes to meet regulatory assurance.

🍺

Brewed Insight: The shift from connected landing zones to platform-owned connectivity mirrors how enterprises are modernising their cloud governance: centralised guardrails, decentralised innovation.
Think of the network as the “brew method” — the beans (your workloads) won’t taste right without the right pressure, filter, and flow.

🔗 Learn More

Brewing the Latest Azure Landing Zone – Identity and Access Foundations

Thu, 13 Nov 2025 00:00:00 +1100

A landing zone without a proper identity model is like a café without portion control—too much espresso and everything goes haywire, too little and nothing works with any punch. The latest Azure Landing Zone (ALZ) design has refined its approach to identity and access, ensuring your platform and workloads aren’t over‑caffeinated with excessive privilege.

In this post, we’ll look at how the ALZ identity layer is structured, how to align with least‑privilege principles, and how tools like Privileged Identity Management (PIM) and Conditional Access keep your digital baristas in check.

What is “Identity and Access Foundations” in ALZ?

In Microsoft’s Cloud Adoption Framework (CAF), Identity and Access Management is one of the core design areas underpinning governance, networking, and operations. It defines how Microsoft Entra ID (formerly Azure AD) authenticates and authorises users, applications, and services.

Within a landing zone, identity foundations mean:

Administrative layers are clearly divided using management groups and subscriptions.
Access follows least privilege and just‑in‑time principles.
Conditional Access (CA) policies and break‑glass accounts are defined from day one.
Platform and workload identities operate independently, reducing blast radius.

Deployed via the ALZ Bicep or Terraform accelerators, these principles become part of your control plane architecture—not an afterthought after workloads land.

How It Works

Identity in an ALZ spans three planes:

Control Plane – Managed through Entra ID and management groups. This is where global policies and Conditional Access live. Only a small, well‑audited team should hold access here.
Platform Layer – Covers shared services such as networking, monitoring, and security. Role assignments here are limited to platform engineers via RBAC.
Workload Layer – Each workload subscription inherits a baseline identity policy while maintaining autonomy for its application teams.

A simple mapping looks like this:

Each layer integrates with Entra roles, Azure RBAC, and PIM to maintain separation between operational, security, and application functions.

Real‑World Impact

When identity is poorly structured, everyone ends up wearing too many aprons—network admins holding Owner rights on production subscriptions, or developers creating service principals with excessive permissions.

By enforcing tiered identity and PIM activation:

Privilege sprawl is drastically reduced.
Operational oversight improves with clear audit trails.
Security breaches are contained—access is temporary, traceable, and justified.
Cross‑team collaboration becomes safer with controlled Entra B2B roles.

It’s a design that scales with your tenancy, not against it.

Implementation Examples

1. Assign Role‑Based Access in Azure Portal

Go to Management Groups → Access Control (IAM).
Assign:
- Owner or Contributor roles only at Platform or Connectivity tiers to core teams.
- Reader or Monitoring Contributor roles for governance visibility.
- Narrow roles (e.g. Network Contributor, Security Reader) for workload subscriptions.

2. Enable Privileged Identity Management (PIM)

Open Entra ID → Privileged Identity Management.
Onboard Azure resources.
Define permanent eligible role assignments (not active).
Require MFA, justification, and approval to activate roles.

3. Bicep Example – Controlled Role Assignment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


param principalId string
param roleDefinitionId string
param scope string

// Assign Network Contributor at platform subscription level
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
 name: guid(scope, principalId, roleDefinitionId)
 scope: scope
 properties: {
 roleDefinitionId: roleDefinitionId
 principalId: principalId
 principalType: 'ServicePrincipal'
 }
}

Example values:

roleDefinitionId: b24988ac-6180-42a0-ab88-20f7382dd24c (Contributor)
scope: /subscriptions/{platformSubscriptionId}

4. Conditional Access + MFA Enforcement

Use Conditional Access in Entra ID → Security → Conditional Access to enforce MFA for administrative roles.
Common patterns:

Require compliant device or Azure AD‑joined machine.
Block access from legacy auth or anonymous IP ranges.
Apply strict policies to Global Administrator, Privileged Role Administrator, and PIM‑eligible roles.

Sovereign Landing Zones and Identity

While most ALZ identity designs target commercial Azure regions, the same principles extend to Microsoft Sovereign Landing Zones (SLZ). These environments service jurisdictions such as Azure Australia Central, Azure Government, and Azure for EU Data Boundary—offering additional isolation and compliance controls.

Key differences include:

Tenant separation – Sovereign or regulated environments may require a dedicated Entra ID tenant, isolated from corporate or commercial directories.
Conditional Access under local policy – CA rules may enforce sovereign network ranges, national ID providers, or hardware‑backed MFA.
PIM activation oversight – Privileged activations often require local approval aligned with regulatory standards (e.g. IRAP, FedRAMP, or EU GDPR).
Identity data residency – Authentication logs and audit data may be restricted to certified national datacentres.

For most enterprises, the identity design principles in this post serve as the baseline for sovereign expansion—the same brew, just filtered through a compliance‑grade portafilter.

Gotchas & Edge Cases

Global Admin concentration: Limit tenant‑wide roles. Use scoped Entra roles like Cloud App Administrator or Security Admin wherever possible.
Automation accounts: Managed identities don’t always bridge cross‑tenant scenarios; consider using app registrations secured with certificates.
PIM activation latency: Factor delays into incident response playbooks.
Break‑glass accounts: Maintain two emergency cloud‑only accounts with monitored sign‑in alerts—never MFA‑disabled by accident.

Best Practices

Model access around management group hierarchy, not ad‑hoc subscription roles.
Group RBAC assignments via Azure AD security groups to simplify lifecycle management.
Enforce Conditional Access with MFA for all administrators.
Separate platform and workload identities—no shared service principals.
Automate credential rotation through Key Vault and managed identity.
Review PIM usage quarterly; revoke stale eligible assignments.
Document ownership boundaries as part of your governance artefacts.
For sovereign deployments, confirm identity residency and tenant isolation requirements early in design.

🍺

Brewed Insight: Identity is the grind setting of your cloud security—too coarse and everything slips through, too fine and no one can do their job. Get it just right with structured access tiers and automation, and your landing zone will run as consistently as your first morning cuppa.

Learn More

Brewing the Latest Azure Landing Zone – Introducing the Secure Landing Zone

Tue, 11 Nov 2025 00:00:00 +1100

Like a precision-engineered espresso machine, a mature Azure environment is all about control — achieving just the right balance between pressure and flow. In our cloud world, that balance exists between security, governance, and operational agility.

The Secure Landing Zone (SLZ) is the mechanism that keeps that balance finely tuned. It’s the dedicated space within your Azure Landing Zone architecture where security, compliance, and trust boundaries converge — the operational embodiment of Sovereign Landing Zone (SoLZ) principles.

As organisations expand beyond their initial Azure foundations, they often need to navigate regulatory compliance, data residency, and strict access separation.
That’s where the SLZ steps in — extending your Azure Landing Zone architecture to deliver sovereign-grade security and control.

What is the Secure Landing Zone?

The Secure Landing Zone (SLZ) builds upon the Azure Cloud Adoption Framework (CAF) design areas to provide a sovereign-ready platform for security operations.

It separates core security capabilities into a distinct management and operational boundary, allowing for strong isolation, independent lifecycle management, and compliance alignment.

The SLZ focuses on:

Security & Compliance – Centrally managing policies, alerting, and detection
Identity & Access – Segregated privileged identities via Microsoft Entra ID
Monitoring & Response – Unified telemetry and automation through Sentinel
Data Sovereignty – Restricting telemetry and data flow to specific regional boundaries

In short, the SLZ is a Sovereign Control Plane for your Azure estate — enforcing identity, policy, and compliance guardrails without constraining day-to-day innovation.

How It Fits in the Landing Zone Hierarchy

The Secure Landing Zone extends the standard Azure Landing Zone layout by introducing controlled, sovereignty‑aware boundaries that mirror the Sovereign Landing Zone (SoLZ) pattern.

By structuring management groups and subscriptions around trust tiers and regional boundaries, the design ensures that sensitive operations and data remain isolated within trusted Azure regions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Tenant Root
├── Platform
│ ├── Identity
│ ├── Management
│ ├── Connectivity
│ ├── Shared Services
│ └── Secure
└── Workloads
 ├── Corp
 ├── Secure-Corp
 ├── Online
 └── Secure-Online

Platform Secure Layer (Sovereign Core)

The Secure management group represents the sovereign control plane of your Azure platform.
This is where you locate:

Microsoft Sentinel (SIEM/SOAR) and Log Analytics — centralised but region‑restricted
Defender for Cloud — managed at scale via policies scoped to this management group
Azure Policy and Governance Initiatives — enforcing security and compliance baselines
Automation and Playbooks — contained within a sovereign data region (e.g., Australia East/Central)

This design ensures that both governance and operational intelligence are processed locally within approved regions, addressing data residency and compliance requirements.

Sovereign Secured Workload Zones

Under each workload domain — Corp and Online — the inclusion of secure-corp and secure-online follows the SoLZ pattern for sovereign application zones. These are specialised sub‑zones dedicated to sensitive or compliance‑bound workloads.

Each secure workload zone is:

Bound to specific sovereign Azure regions via the “Allowed Locations” policy
Connected only via the Connectivity Platform, using private endpoints and hub-spoke topology
Subject to delegated Defender for Cloud policies while reporting telemetry back to the Platform Secure workspace
Compliant by default, using Azure Policy and RBAC definitions inherited from the sovereign control plane

These secure subzones act as sovereign enclaves — maintaining isolation, compliance posture, and audit traceability.

graph TD A[Tenant Root] A --> B[Platform] B --> B1[Connectivity] B --> B2[Identity] B --> B3[Management] B --> B4[Shared Services] B --> B5["Secure Platform (Sovereign Control Plane)"] A --> C[Workloads] C --> C1[Corp] C1 --> D1["Secure-Corp (Sovereign Zone)"] C --> C2[Online] C2 --> D2["Secure-Online (Sovereign Zone)"]

Real‑World Impact

In regulated and defence-grade organisations across Australia, these Secure Landing Zones deliver measurable benefits:

Data residency assurance. Telemetry and logs never leave sovereign regions.
Reduced blast radius. Platform and workload security scopes remain strictly separated.
Centralised compliance. Security policies, audit logs, and Defender alerts flow to a single, sovereign workspace.
Operational clarity. Security personnel manage the SLZ; application teams focus on workloads.

By adopting an SLZ following Sovereign Landing Zone principles, teams accelerate their security maturity without complicating operational models.

Implementation Examples

Portal Deployment Sequence (High Level)

Create a Secure management group under Platform and deploy a dedicated security subscription.
Deploy Log Analytics, Microsoft Sentinel, and Azure Automation in a sovereign region.
Apply Defender for Cloud standard plans across the Secure management group.
Assign sovereign and security policy initiatives targeting compliance (e.g. ISO27001, IRAP, or Essential Eight).
Build secure‑corp and secure‑online subscriptions for sovereign application workloads.
Configure private connectivity and telemetry flow back into the Secure platform workspace.

Example Bicep Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


@description('Prefix for secure landing zone resources')
param prefix string = 'secure'

@description('Region for sovereign deployment')
param location string = 'australiaeast'

resource secureLog 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
 name: '${prefix}-law'
 location: location
 sku: {
 name: 'PerGB2018'
 }
 properties: {
 retentionInDays: 30
 }
}

resource sentinel 'Microsoft.SecurityInsights/onboardingStates@2022-11-01' = {
 name: '${prefix}-sentinel'
 scope: secureLog
 properties: {}
}

resource defender 'Microsoft.Security/pricings@2022-03-01' = {
 name: 'VirtualMachines'
 properties: {
 pricingTier: 'Standard'
 }
}

This configuration ensures sovereignty by constraining deployment to an Australian region and centralising all SIEM and Defender activity within the Secure Platform boundary.

Gotchas & Edge Cases

Policy overlap across management groups – Validate inheritance to avoid conflicting enforcement when sovereign policies cross scopes.
Telemetry costs – Data retention and SIEM ingestion in sovereign regions can be higher due to compliance logging. Plan retention carefully.
Defender plan overuse – Avoid enabling every plan globally; use management group scoping to control coverage.
Identity segregation – Maintain Entra Privileged Identity Management (PIM) separation between platform and workload identities.

Best Practices

✅ Create a dedicated Secure management group under Platform to host all SLZ resources.
✅ Deploy Sentinel and Defender for Cloud in compliance-approved Azure regions only.
✅ Use “Allowed Locations” and “Audit VNet Peering” policies to guarantee sovereign network boundaries.
✅ Follow the Sovereign Landing Zone reference architecture for structured isolation.
✅ Keep all automation, alerting, and telemetry private — no Internet dependencies.
✅ Apply least privilege (RBAC/PIM) and separate operational lifecycles for Secure, Corp, and Online zones.

🍺

Brewed Insight: The Secure Landing Zone is the espresso shot of sovereignty — concentrated, deliberate, and potent.
It’s not just about compliance; it’s about trust and autonomy. Adopting Sovereign Landing Zone principles ensures your Azure environment is ready to meet both local regulation and global security standards without sacrificing agility.

Learn More

Brewing the Latest Azure Landing Zone – The Anatomy of an ALZ

Thu, 06 Nov 2025 00:00:00 +1100

Designing an Azure Landing Zone (ALZ) can feel like crafting the perfect flat white, you need the right blend of structure and flexibility, delivered consistently every time. Miss the proportions and you’ll either over‑govern or under‑secure your environment.

With Microsoft’s latest ALZ guidance evolving through the Cloud Adoption Framework (CAF), understanding what makes up an ALZ, and how these pieces interlock, is key to setting up a platform that scales cleanly across workloads and teams.

In this post, we’ll unpack the anatomy of an ALZ from the ground up: management groups, baseline services, connectivity, logging, and what parts are open for customisation versus “hands‑off” prescriptive control.

What is an Azure Landing Zone?

An Azure Landing Zone (ALZ) is a collection of Azure resources, policies, and configurations that establish a secure and governed foundation for deploying workloads. It’s essentially the “control plane” for the rest of your cloud estate — defining how resources are structured, secured, and connected.

Microsoft’s Cloud Adoption Framework (CAF) describes ALZs as reference implementations that help organisations balance enterprise guardrails with developer agility. They span critical design areas such as:

Identity and access management
Network topology and connectivity
Security and compliance baseline
Resource organisation and policy
Monitoring and management

The current ALZ architecture (v3 and beyond) continues to evolve toward modularity and automation, allowing partial or full deployment through templates, pipelines, or tools like Azure Developer CLI (azd).

How It Works

Every ALZ is built around a management group hierarchy, baseline policies, governance services, and shared platform resources. Think of it as the skeleton of your Azure estate.

1. Management Group Hierarchy

At the top sits the Tenant Root Group, followed by a recommended structure like this:

1
2
3
4
5
6
7
8
9


Tenant Root
 ├── Platform
 │ ├── Identity
 │ ├── Management
 │ ├── Connectivity
 │ └── Shared Services
 └── Workloads
 ├── Corp
 └── Online

Each branch enforces scope‑specific policy assignments and role inheritances.

For example:

Platform → central services like Firewall, DNS, and Hub networks
Corp → internal workloads following restricted egress/internet controls
Online → internet‑facing or public workloads with isolated routing

A simplified Mermaid diagram helps illustrate this structure.

graph TD A[Tenant Root Group] A --> B[Platform] A --> C[Workloads] B --> D[Identity] B --> E[Management] B --> F[Connectivity] C --> G[Corp] C --> H[Online]

2. Baseline Services

Under the Platform branch, Azure policy, Defender for Cloud, logging, and network topologies take shape:

Azure Policy and Initiative Assignments: Enforce naming, tagging, resource restrictions, security mandates, and region constraints.
Defender for Cloud (DfC): Enables Cloud Security Posture Management (CSPM) and threat protection across subscriptions.
Networking: Hub‑and‑spoke is still the go‑to, though the Virtual WAN model is gaining traction for global routing needs.
Monitoring: Azure Monitor, Log Analytics, and Activity Logs are centralised in a management subscription for visibility and response.

3. Connectivity and Hub-and-Spoke Evolution

The “Connectivity” management group or subscription houses baseline resources such as:

Virtual Network (Hub)
Network Security Groups (NSGs) and Azure Firewall
Private DNS zones
VPN/ExpressRoute Gateways

Many teams now use Virtual WAN hubs for unified global routing and security, combining multiple regions or geographies into a standardised topology.

4. Control Plane vs. Workload Plane

An ALZ effectively splits your estate into two operating domains:

Control Plane: The policies, RBAC assignments, and platform resources managed typically by a central platform team.
Workload Plane: Application subscriptions that inherit governance and integrate using shared services.

This separation enables autonomy without loss of oversight — the hallmark of a mature Azure platform.

Real‑World Impact

A well‑structured ALZ provides three tangible benefits to real‑world operations:

Faster workload onboarding — Teams can deploy workloads without re‑creating identity, networking, or monitoring from scratch.
Consistent compliance — Built‑in policies ensure resources automatically align with regulatory or security requirements.
Scalable governance — As new workloads or business units appear, they slot neatly into the existing hierarchy with inherited guardrails.

Example: A financial services customer adopted the latest ALZ baseline and halved provisioning time for new environments, while achieving automatic DfC coverage across all subscriptions.

Implementation Examples

Using the Azure Portal

Navigate to Azure Landing Zone Accelerator in the Azure Portal.
Select Deploy to Azure using the CAF‑aligned Bicep templates.
Choose your management group root and desired topology (Hub & Spoke or VWAN).
Review policy and role assignments, then deploy baseline resources.

Bicep Example

A shortened snippet defining part of the management group hierarchy and a policy assignment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


targetScope = 'tenant'

resource platformMgmtGroup 'Microsoft.Management/managementGroups@2021-04-01' = {
 name: 'mg-platform'
 displayName: 'Platform'
 parent: {
 id: tenantResourceId('Microsoft.Management/managementGroups', 'tenant-root')
 }
}

resource workloadsMgmtGroup 'Microsoft.Management/managementGroups@2021-04-01' = {
 name: 'mg-workloads'
 displayName: 'Workloads'
 parent: {
 id: tenantResourceId('Microsoft.Management/managementGroups', 'tenant-root')
 }
}

resource policyAssign 'Microsoft.Authorization/policyAssignments@2021-06-01' = {
 name: 'audit-tagging'
 properties: {
 displayName: 'Audit required tags'
 policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/audit-tags'
 scope: platformMgmtGroup.id
 }
}

This modular design means the same hierarchy can be reused or modified via pipelines or automation frameworks.

Gotchas & Edge Cases

Policy Overlaps: Avoid redundant policy assignments between management groups; precedence can override higher‑level settings unexpectedly.
Hub Peering Limits: Virtual network peers across regions can hit subscription or region limits; plan capacity early.
Role Assignment Delays: Tenant‑level role changes can take minutes to propagate, complicating automated deployments.
Cross‑Tenant Scenarios: ALZ assumes single‑tenant governance; cross‑tenant or B2B integration often needs manual override policies.

Best Practices

Start with the CAF Baseline and customise incrementally—don’t boil the ocean on day one.
Separate Platform and Workload subscriptions to maintain isolation.
Enable Defender for Cloud early for unified posture management.
Centralise monitoring and logs using Azure Monitor and Sentinel.
Template everything — deploy ALZ Scaffolding with Bicep or Terraform to stay consistent across environments.
Use feature flags or config maps to control rollout of new policies safely.

Brewed Insights

Your ALZ is only as strong as its hierarchy. Treat it like the espresso shot in your morning brew — get the foundation right, and everything built on top flows smoother. Naming “Workloads” instead of “Landing Zones” keeps the hierarchy intuitive and clear for stakeholders managing real application estates.

Learn More

Brewing the Latest Azure Landing Zone – What’s New and Why It Matters

Tue, 04 Nov 2025 00:00:00 +1100

If your organisation’s Azure environment has ever started to resemble a messy workbench, with half‑finished projects, cables everywhere, and no one sure who owns what then you already understand why Azure Landing Zones (ALZ) exist.

The latest refresh of Microsoft’s Azure Landing Zone and Secure Landing Zone architecture is like upgrading from a faithful stovetop espresso to a precision‑calibrated machine: same goal, but vastly improved consistency, control, and flavour.

This post breaks down what’s new, how the reference design has evolved, and why it’s now easier than ever to create compliant, secure, and scalable environments from day one.

What is an Azure Landing Zone?

An Azure Landing Zone is Microsoft’s reference architecture and deployment pattern for building a secure, governed cloud foundation. It defines how to organise resources, apply policy, manage identity, and connect workloads. It’s the scaffolding every Azure environment should start from.

From Enterprise‑Scale to the Unified ALZ

Older architectures like Enterprise‑Scale Landing Zone and CAF foundations acted as blueprints for large enterprises. However, Microsoft has now folded those frameworks directly into the unified Azure Landing Zone guidance. The goal: a single, modular reference that fits startups through to global multi‑tenant enterprises.

So rather than a single monolith of templates, ALZ now offers a modular, design‑area‑driven approach where you choose which elements to adopt, iterate on them over time, and evolve the platform in step with cloud maturity.

The Eight Core Design Areas

The latest design defines eight interconnected areas, each representing a pillar of your landing zone foundation:

#	Design Area	Focus
1	Identity and Access Management (IAM)	Microsoft Entra ID foundations, RBAC design, Privileged Identity Management (PIM), and conditional access strategy.
2	Network Topology and Connectivity	Hub‑and‑spoke or Virtual WAN, hybrid connectivity, DNS, and Private Link design.
3	Resource Organisation	Management group hierarchy, subscription strategy, and consistent naming and tagging standards.
4	Governance and Compliance	Azure Policy, Resource Locks, Defender for Cloud, and cross‑environment guardrails.
5	Security, Operations and Policy	Baseline configurations for threat protection, central log collection, and secure configuration enforcement.
6	Management and Monitoring	Azure Monitor, Log Analytics, Automation Accounts, and service health visibility.
7	Business Continuity and Disaster Recovery (BCDR)	Backup, site recovery, multi‑region workloads, and resilience planning.
8	Platform Automation and DevOps	Infrastructure‑as‑Code (IaC), CI/CD pipelines, GitOps processes, and automated configuration drift management.

These areas combine to form an adaptable foundation governed by Landing Zone and Secure Landing Zone reference models.

How It Works

The Landing Zone design leverages Azure’s native control plane hierarchy The Entra ID tenant, management group, subscription, resource group, and resource — to distinguish governance from workload operations.

Below is a simplified view of the reference structure using updated terminology:

🍺

Brewed Insight:

I am NOT a fan of using the term “Landing Zones” within a Landing Zone design I feel like I get caught over explaining the difference or confusing customers when I am speaking about a specific space within the design and they think I am talking about the holistic design or visa versa.

To avoid this confusion I relabel “Landing Zones” as Workloads. I feel this provides a better definition of the space and the subsequent subscriptions and resources

graph TD TENANT[Entra ID Tenant] TENANT --> MGRoot[Root Management Group] MGRoot --> MGPlatform[Platform] MGRoot --> MGLandingZones[Workloads] MGPlatform --> MGIdentity[Identity] MGPlatform --> MGConnectivity[Connectivity] MGPlatform --> MGSecurity[Central Security] MGPlatform --> MGManagement[Management] MGLandingZones --> SubWorkload1[Workload A Subscription] MGLandingZones --> SubWorkload2[Workload B Subscription] SubWorkload1 --> RG1[Resource Groups / Apps] SubWorkload2 --> RG2[Resource Groups / Data]

This structure enables tight control of policy inheritance and delegation, ensuring that corporate standards cascade from the top management groups but still allow agility within workload subscriptions.

What’s Changed in the Latest Reference Design

Secure Landing Zone (SLZ) Becomes First‑Class
Security controls are no longer a bolt‑on. SLZ is now an integral model with pre‑mapped controls aligning directly to Zero Trust and Defender for Cloud benchmarks.
Eight‑Area Alignment
The legacy “design principle” view is now formalised into these eight well‑defined areas, which together cover every subscription lifecycle from governance to DR.
Automation‑First Paradigm
Microsoft’s emphasis has shifted: Landing Zones should be deployed and maintained via automation pipelines, not manual configurations. The supporting ALZ‑Bicep repository and modular template packages make this achievable.
Platform Resources Redefined
The hierarchy now groups Identity, Connectivity, and Security under Platform Resources — clarifying ownership boundaries and improving access segregation.
Enhanced Resilience Focus
ALZ now embeds BCDR as a design area, recommending Azure Backup, Site Recovery, and region pairing guidance as baseline expectations.
Retirement of Enterprise‑Scale Terminology
The previous ESLZ guidance is now deprecated in favour of this unified pattern. The concepts remain, but the language and modularity are refined.

Real‑World Impact

☕ Customer 1 – Greenfield Azure: A Clean Start with Guardrails

A mid‑sized enterprise is preparing to migrate from its on‑prem environment — a single flat network with little role segmentation or billing separation — into Azure.
They’ve built a consistent naming convention locally but know it’s not directly cloud‑ready.

Their priorities:

Segment environments into Prod, Dev, Test, and DMZ tiers.
Maintain consistent security and policy enforcement without added complexity.
Avoid unnecessary spend by keeping the network layout simple.
Centralise connectivity through a hub‑and‑spoke or Virtual WAN topology.

Using the Azure Landing Zone design areas, the roadmap looked like this:

Resource Organisation & Governance:
Adopted the standard management group hierarchy (Platform, Workloads, Management), applying environment tags and subscription separation per environment.
CAF‑aligned naming conventions were re‑tooled to ensure scalability across environments.
Network Topology and Connectivity:
Built a shared Connectivity subscription hosting the hub virtual network and Azure Firewall Manager. Spokes represented the segmented environments (Prod, Dev, etc.), each with segregated subnets but governed by central routing and policy.
Secure Landing Zone:
Security baselines were enforced through pre‑built policy initiatives — encrypting storage accounts, restricting VM SKUs, and standardising region deployment.

Outcome:
Within weeks, the customer established a clean, well‑segmented environment with predictable connectivity and security built‑in. They avoided sprawl and surprise charges while achieving a structure ready for workload migrations.

☕ Customer 2 – Brownfield Azure: Evolving Towards the Landing Zone Pattern

Another customer already operates in Azure but realises their environment has grown organically — inconsistent tagging, scattered resources, and no clear linkage between dev, test, and production workloads.

Their challenges:

Existing structure doesn’t fully align with the proposed Landing Zone pattern.
Tagging taxonomy is inconsistent and not providing real business value.
Desire to centralise connectivity for better security visibility and control.
Need to apply policy guardrails to limit region sprawl and costly VM SKU choices.

Their approach:

Assessment via CAF Readiness Review:
Mapped the current environment against the eight design areas to identify remediation scope and technical debt.
Incremental Landing Zone Adoption:
Decided not to “lift‑and‑shift” the entire estate, but instead deploy the new ALZ structure in parallel. Existing production workloads started migrating gradually, while new projects launched directly inside Landing Zone subscriptions.
Automation and Governance Enhancements:
Introduced Azure Policy initiatives for allowed SKUs, region restrictions, and tagging enforcement.
Leveraged Azure Resource Graph queries to discover and remediate old resources outside governance boundaries.
Centralised Connectivity:
Built a new hub network under the Platform management group and rerouted spokes via Virtual Network Peering.
This central hub established consistent ingress/egress controls and visibility via Network Watcher and NSG Flow Logs.

Outcome:
Within a few months, the organisation achieved much better visibility, control, and cost predictability.
While legacy resources still coexist, the Landing Zone architecture provided a north star for modernisation — replacing chaos with incremental, systematic improvement.

Both cases show how Azure Landing Zones are not only for new cloud adopters but also a practical refactoring target for existing Azure estates.
Whether greenfield or brownfield, the framework turns fragmented footprints into repeatable, monitored, and governed platforms — proving that the perfect brew is achievable, even when you start with yesterday’s grounds.

Implementation Examples

Deploy via Azure Portal

Open the Azure Landing Zone Accelerator.
Select the Secure Landing Zone definition.
Configure:
- Management Group hierarchy
- Connectivity type: Hub‑Spoke or Virtual WAN
- Defender for Cloud plan onboarding
Deploy directly or export configuration for IaC pipeline integration.

Bicep Foundation Example

Here’s a refreshed sample to spin up the management group scaffolding from Automation pipelines:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


param rootMG string = 'mg-root'

resource mgManagement 'Microsoft.Management/managementGroups@2021-04-01' = {
 name: 'mg-management'
 parentId: tenantResourceId('Microsoft.Management/managementGroups', rootMG)
 displayName: 'mg-management'
}

resource mgPlatform 'Microsoft.Management/managementGroups@2021-04-01' = {
 name: 'mg-platform'
 parentId: tenantResourceId('Microsoft.Management/managementGroups', rootMG)
 displayName: 'mg-platform'
}

resource mgLanding 'Microsoft.Management/managementGroups@2021-04-01' = {
 name: 'mg-workloads'
 parentId: tenantResourceId('Microsoft.Management/managementGroups', rootMG)
 displayName: 'mg-workloads'
}

You can then import the modular ALZ‑Bicep packages for policies, connectivity, and monitoring:

1
2
3


az bicep install
bicep install az:alz
bicep build ./main.bicep

Gotchas & Edge Cases

Policy sequencing: Order of policy assignments still matters. Deploy policy baseline modules before workload‑specific ones to avoid blocking legitimate resources.
Cross‑tenant identity: Multi‑directory environments may require explicit configuration for Entra cross‑tenant access.
CIDR overlap: When migrating legacy hubs, ensure address space planning aligns with vWAN or secure hub modules.
Drift detection lag: If automation is disabled, ALZ configurations can drift — leverage compliance scans and DevOps triggers to correct automatically.

Best Practices

Adopt ALZ components incrementally — not every design area needs to be deployed on day one.
Use Bicep or Terraform pipelines for repeatable deployment and compliance validation.
Map landing zone policy initiatives directly to CAF policy categories for clarity in audits.
Integrate Defender for Cloud and Log Analytics early to baseline secure posture.
Apply Privileged Identity Management (PIM) for tenant and management group administrators.
Align naming and tagging conventions with your Resource Organisation strategy.
For resiliency, configure Geo‑replicated backups and pair regions for core workloads.
Treat Automation and DevOps as part of platform design, not post‑deployment tooling.

🍺

Brewed Insight: The latest Azure Landing Zone release isn’t just another iteration it’s a maturity moment. Governance, security, automation, and resilience have merged under one consistent pattern. Think of it as refining your brewing process: same beans, better extraction. With the new ALZ, your cloud foundation is engineered for scale and repeatability, not just deployment speed.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Regular Backups

Thu, 30 Oct 2025 00:00:00 +1100

A good cold brew is all about preparation and patience. You steep it overnight, untouched, so it’s ready when the temperature rises. Backups are no different they only matter when things go wrong, but they’re useless if not carefully prepared.

In Azure Virtual Desktop (AVD) or Windows 365 (W365), solid backup practices are what transform a simple outage into a quick recovery.

What is “Backups”?

Under the ACSC Essential 8, the Backup control is all about resilience: being able to recover critical systems, data, and configurations after a breach, ransomware event, or mistake.

For Maturity Level 2, backups must:

Run automatically and be retained per business criticality
Be synchronised for consistent point‑in‑time recovery
Be stored securely and tested regularly
Be protected against unauthorised modification or deletion

In short — a working recovery plan with provable isolation and integrity.

How It Works in Cloud VDI

Azure Virtual Desktop (AVD)

AVD operates across several Azure layers:

User profiles and data – FSLogix containers stored in Azure Files or Azure NetApp Files
Session hosts – Azure Compute virtual machines
Configuration definitions – ARM or Bicep templates, PowerShell
Dependent services – Azure SQL, Key Vault, or Azure Storage

Backups apply differently at each layer:

Protect Azure Files with Azure Backup or NetApp volume snapshots.
Back up session‑host VMs using Recovery Services Vaults. In multi‑host designs, use gold‑image version control rather than backing up each instance.
Store all Infrastructure‑as‑Code (Bicep, ARM, JSON) in version‑controlled repositories to allow environment rebuilds at short notice.

Backups for AVD environments should also use immutable Recovery Services Vaults with Geo‑Redundant Storage (GRS) enabled to deliver true ML2‑grade resilience.

Windows 365 (W365) and Microsoft 365 Data Protection

Windows 365 abstracts almost all infrastructure layers, leaving Microsoft 365 to manage user data protection. In this model, your ability to restore depends on the native data‑protection features built into the Microsoft 365 stack.

What Microsoft provides:

OneDrive for Business: Version history, 30‑day file restore, and a 93‑day recycle bin.
SharePoint Online: Dual‑stage recycle bins retained for 93 days, and library versioning.
Exchange Online: Item‑level recovery and deleted‑item retention (default 30 days, extendable), underpinned by database‑level replication and availability groups.
Platform replication: Microsoft maintains multi‑region replication for service continuity and platform‑level resilience.

These measures support availability, limited retention, and short‑term recovery, but do not fully meet Essential 8 ML2 requirements. Microsoft’s protection model is designed for service continuity, not for tenant‑controlled backup. You cannot make data immutable, restore a complete site at will, or isolate copies from the production tenancy.

To close this compliance gap, many organisations deploy cloud‑to‑cloud backup solutions such as ConnectWise M365 Backup (formerly SkyKick) or Veeam Backup for M365. These tools:

Keep independent, immutable copies of OneDrive, SharePoint, and Exchange data.
Offer region‑specific replication and flexible retention schedules.
Support granular, point‑in‑time recovery aligned to business and compliance objectives.

Using third‑party M365 backups moves tenant data under your administrative control the critical step needed to achieve ML2 alignment for Microsoft 365 workloads supporting W365 users.

Immutable Backups – Hands Off, Locked Tight

Immutable backups are those that cannot be modified or deleted until their retention period ends. In Azure this is delivered using Immutable Vaults.

Why it matters:

Stops ransomware dead — even compromised credentials can’t alter or remove stored copies.
Eliminates insider tampering — backup and platform admins can’t purge protected data.
Supports audit and compliance — the vault enforces evidence of retention integrity.

Once locked, backups remain intact until the specified retention period ends — the digital equivalent of sealing a litre of cold brew and labelling it hands off until morning.

Backup Resiliency with Geo‑Redundancy

Resilient backups survive not just tampering but regional disasters.
Setting your Recovery Services Vault to Geo‑Redundant Storage (GRS) replicates backup data to a paired Azure region.

When enabled:

Backups are written to both primary and secondary regions.
In a regional outage, Microsoft can initiate recovery from the secondary region.
Combined with immutability, this provides both off‑site protection and change‑proof retention — ideal for ML2 compliance.

Portal path:

Open your Recovery Services Vault
Under Properties → Backup Configuration, select Geo‑Redundant Storage
Ensure Soft Delete and Immutable Vault are both enabled

Implementation Flow

flowchart TD AVD[Azure Virtual Desktop] --> FS["FSLogix Containers - Azure Files"] FS --> Vault["Recovery Services Vault (Immutable + GRS)"] Vault --> TestRestore["Tested Restore / DR Exercise"] subgraph M365 [Windows 365 + Microsoft 365] U1[Cloud PC Users] --> OD["OneDrive / SharePoint / Exchange Online"] OD --> Protect["Microsoft Data Protection - Versioning, Retention"] Protect --> Backup3P["Optional Tenant-Controlled Backup Platform (e.g. ConnectWise M365 Backup)"] end

Real‑World Impact

Immutable and geo‑resilient backups bring calm to otherwise chaotic recovery moments. Without them, ransomware or an administrator’s mis‑click could erase both production and recovery data in an instant.

A properly designed plan:

Enables rapid, point‑in‑time recovery from isolated data copies
Provides cross‑region durability for continuity
Defends against insider and external tampering
Demonstrates tested, auditable control for compliance

For AVD and W365 alike, that’s the difference between a minor outage and a week of downtime.

Best Practices

Enable Immutable Vaults with GRS for all AVD critical file shares and backup vaults.
Activate Soft Delete to guard against unexpected purge operations.
Tighten RBAC on Recovery Services Vaults; restrict “restore operator” privileges.
Store infrastructure definitions in source control for rapid environment rebuilds.
Test restores quarterly; record results to evidence DR capability.
For Microsoft 365 tenants, deploy independent backup where compliance or legal retention requires isolation.

🍺

Brewed Insight: Microsoft’s native protection is like keeping a backup jug of cold brew in the same fridge as the main batch — safe from small spills but not from a power cut.
Adding immutable, geo‑redundant Azure backups and independent M365 backups is like moving that jug across town to a powered cellar: slower to set up but rock‑solid when everything else melts down.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – User Application Hardening

Tue, 28 Oct 2025 00:00:00 +1100

We’ve all had that one poorly made coffee that somehow ruins your morning flow — bitter, messy, and impossible to fix once poured. In many ways, unprotected applications in a virtual desktop are the same. A single dodgy browser plugin or outdated PDF reader can completely spoil your security blend. That’s where User Application Hardening comes in. It keeps the bad add-ins and malicious macros from spilling into your users’ sessions.

What is User Application Hardening?

User Application Hardening is one of the Australian Cyber Security Centre (ACSC) Essential Eight strategies. At Maturity Level 2 (ML2), it’s all about reducing exposure in user-facing applications — browsers, Office apps, PDF readers, and similar — by removing or disabling risky capabilities.

In plain terms, it means:

Removing Internet Explorer 11
Disabling Java, Flash, and other deprecated script engines
Blocking Office from running macros, injecting code, or launching child processes
Hardening PDF readers to prevent malicious scripts

These changes collectively close high-frequency exploitation routes that adversaries love to abuse.

How it Works in Cloud VDI

For both Azure Virtual Desktop (AVD) and Windows 365 Cloud PCs, these controls are applied through centralised management and policy enforcement. The approach differs slightly depending on how compute sessions are delivered.

Azure Virtual Desktop (AVD):
Multi-session environments typically use a golden image that includes hardened apps and preconfigured baselines. Configuration policies are applied using Microsoft Intune, Group Policy Objects (GPOs), and Defender for Endpoint integration via the session host templates.
Windows 365:
Each Cloud PC runs as a dedicated instance for a single user. Intune device policies and security baselines map directly to each machine, which simplifies lifecycle management.

Policy Flow Diagram

flowchart LR A[Intune & Defender Policies] --> B{Policy Delivery} B --> C[Azure Virtual Desktop Session Hosts] B --> D[Windows 365 Cloud PCs] C --> E["Applications Hardened (Edge, Office, Acrobat Reader)"] D --> E E --> F["Telemetry sent to Defender / SIEM"] F --> G[Security Operations Centre for Analysis]

This unified approach enforces restriction policies across the environment and provides telemetry for continuous oversight through Defender and log integrations.

Real-World Impact

Attackers exploit what users trust most — browsers, email attachments, spreadsheets, and documents. Once embedded in a malicious payload, even an Office macro can deliver PowerShell commands or dropper scripts within seconds.

User Application Hardening directly trims these attack surfaces. When paired with logging and timely analysis, it creates a resilient, self-defending virtual desktop environment that meets both ACSC ML2 obligations and enterprise expectations for modern security operations.

The business outcome: fewer incidents, faster detection, and a far more predictable user experience.

Implementation Example

Intune

You can deliver application hardening through a single, unified Intune policy that implements all required ML2 browser, Office, and PDF settings.

Step 1 – Create a consolidated configuration profile

In the Microsoft Intune admin centre, go to Endpoint Security → Security Baselines → Microsoft Edge baseline.
Select Create Profile and assign a clear name such as Essential8-UserApplicationHardening-ML2.

Apply the following browser protection settings derived from both ASD and Microsoft guidance:

Category	Setting	Recommended Value
SmartScreen	Require SmartScreen for URLs	Enabled
Plugins	Allow Adobe Flash and Java	Disabled
Tracking Prevention	Apply Strict Mode	Enabled
Extensions	Block unapproved extensions	Enabled
Security Updates	Disallow user override of update policy	Enabled
IE Mode	Disable IE Integration	Enabled
JavaScript	Allow only signed scripts from trusted zones	Enabled
Site Security	Prevent site isolation overrides	Enabled

Assign the profile to both AVD session host and Windows 365 device groups.

This single policy ensures browsers are protected against common vectors such as Java-based web content, Flash exploits, and malicious ads or extensions.

Step 2 – Office and PDF Hardening

Add the Microsoft 365 Apps Baseline to disable macro execution from the Internet and restrict add-ins to trusted publishers.
Enforce ASR rules to block child process creation, executable content, and code injection:
- D4F940AB-401B-4EFC-AADC-AD5F3C50688A (Child Processes)
- 3B576869-A4EC-4529-8536-B80A7769E899 (Executable Content)
- 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 (Code Injection)
Deploy a custom configuration profile for PDF readers disabling JavaScript (bDisableJS=1) and network features.

Step 3 – Defender for Endpoint Integration

Integrate hardening with Defender for Endpoint to manage and enforce ASR rules automatically:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


resource avdVmExtension 'Microsoft.Compute/virtualMachines/extensions@2022-11-01' = {
 name: 'AVD-Defender-Policy'
 parent: avdSessionHost
 properties: {
 publisher: 'Microsoft.Azure.Security'
 type: 'MDE.Windows'
 typeHandlerVersion: '1.0'
 autoUpgradeMinorVersion: true
 }
}

Logging, Monitoring, and Timely Analysis

ML2 goes beyond configuration — it demands that logs are collected, retained, and analysed in a timely manner to detect and respond to threats.

That means enabling and centralising:

Command-line process creation events (Event ID 4688)
PowerShell script and block logging (Events 4103 and 4104)
Defender for Endpoint telemetry
Application event logs for Office, Edge, and Acrobat

Logs should funnel into a single collection point for active analysis — not passive storage. This is where a Security Operations Centre (SOC) capability becomes essential.

If you already operate an in-house SOC, integrate AVD and Windows 365 telemetry into your existing monitoring workflows through Microsoft Sentinel.

If you don’t, consider:

Huntress SIEM – a streamlined, cloud-based offering ideal for smaller environments looking to meet ML2 logging analysis obligations, or
A Managed Sentinel deployment delivered through a Microsoft partner providing continuous SOC monitoring, threat correlation, and response capability.

The ACSC expectation is that indicators of compromise are identified and acted on quickly — it’s not compliance until there’s detection with action behind it.

Gotchas & Edge Cases

Dual Configuration Sources: Avoid policy conflicts between Intune and GPO; choose a single management authority.
Macro-Dependent Workflows: Use digitally signed macros or trusted locations instead of disabling macros entirely.
PDF Vendor Support: Ensure your preferred PDF tool supports configuration at policy level.
SOC Gaps: Logging without analysis breaches ML2 intent. Every control should have someone — or something — watching logs for anomalies.

Best Practices

Use Microsoft Security Baselines as a foundation and overlay ACSC guidance.
Harden images upstream for AVD; redeploy session hosts from a clean, compliant golden image.
Link to Defender for Endpoint early to capture telemetry.
Enable SIEM integration from day one to meet the “timely analysis” requirement.
Automate validation using PowerShell scripts and Azure Policy compliance checks.
Document deviations and review them quarterly to retain ML2 alignment.

🍺

Brewed Insight: Like brewing a double-shot, this control is all about pressure and precision. Tighten policies too hard and workflow suffers; too loose, and your security posture leaks. The right blend of Intune policies, Defender enforcement, and SOC visibility keeps your digital espresso crisp and strong every time.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Restricting Admin Privileges

Thu, 23 Oct 2025 00:00:00 +1100

You wouldn’t hand the bar keys to every patron on a Saturday night, right? The same logic applies to administrative rights in your cloud VDI estate.
When every user has a pint-sized admin role, one bad click can spill into an incident faster than a dropped schooner. Restricting administrative privileges isn’t about mistrust—it’s about measured access to keep your environment clean and secure.

What is “Restrict Administrative Privileges”?

The Restrict Administrative Privileges control is one of the Australian Cyber Security Centre (ACSC) Essential 8 strategies.
Its goal is to limit the number and duration of accounts with administrative rights. These privileges should be assigned only when necessary, tightly monitored, and revoked once not in use.

At Maturity Level 2, organisations are expected to:

Use separate accounts for administration and day-to-day work
Implement just-in-time privileged access using tools such as Microsoft Entra Privileged Identity Management (PIM)
Conduct periodic revalidation of privileged access (e.g., every 12 months)
Remove inactive privileged roles after 45 days
Ensure all administrative actions are centrally logged, monitored, and auditable
Enforce restricted internet and email access for privileged accounts

How it Works in Cloud VDI

Azure Virtual Desktop (AVD) and Windows 365 both host user desktops in the Microsoft cloud, but how we manage privilege varies depending on desktop persistence and management scope.

Azure Virtual Desktop (AVD)

AVD session hosts are multi-user machines, rebuilt frequently via automation.
Admin privileges should be granted temporarily via Azure AD roles or local group membership managed through tools like Azure AD Group Policy Objects (GPOs) or Intune Device Configuration Profiles.
Use PIM to assign Virtual Machine Administrator Login and Virtual Machine Contributor roles just in time to trusted users.
Configure access reviews and expiry policies in PIM to automatically remove inactive roles (45 days) and revalidate eligibility every 12 months.
For delegated operations (e.g., image updates or session host management), prefer Azure RBAC over local admin accounts.
When performing privileged actions, connect through a jump host or secure AVD management pool—not from general user sessions.

Windows 365 (W365)

W365 Cloud PCs are persistent, single-user desktops.
Admin rights should be avoided for standard users and only enabled on a per-device basis with Intune Endpoint Privilege Management (EPM) or temporary local admin assignment.
For IT admins, management should occur via Intune or Microsoft Endpoint Manager portals—not by logging into the Cloud PC itself.
Use Cloud PCs as Privileged Access Workstations (PAWs) for administration duties, ensuring these environments are isolated and do not overlap with unprivileged desktops.

Leveraging Cloud VDI as a Privileged Access Workstation (PAW)

A well-brewed privileged access model often hinges on the workstation itself. Whether you prefer AVD for ephemeral sessions or W365 for persistent access, both can serve as controlled brewing vessels for secure administration.

1. Azure Virtual Desktop as a Secure Admin Pool

Goal: Provide short-lived, locked-down desktops for privileged activities inside Azure or Microsoft 365.

Approach:

Create a dedicated host pool for privileged operations separate from the user host pool.
Configure each session host with Intune or GPO hardening:
- Block browsers, email, and non-essential software.
- Require MFA and device compliance via Conditional Access.
- Enable Microsoft Defender for Endpoint and attack surface reduction.
Use PIM to grant Virtual Machine Administrator Login roles only when required.
Set up ephemeral hosts that reset after logoff—each session is freshly brewed.

Use case:
Cloud administrators log into the “Admin Pool,” elevate through PIM, perform administrative tasks, then sign out. The VM resets, purging cached credentials and leaving a minimal attack surface.

2. Windows 365 Enterprise as a Persistent PAW

Goal: Provide a dedicated, always-available workstation for tenant administration.

Approach:

Deliver a Cloud PC SKU per privileged identity.
Manage exclusively via Microsoft Intune:
- Apply Endpoint Privilege Management for temporary elevation.
- Enforce application control and hardening baselines.
- Restrict internet and email via app policies and Conditional Access.
- Integrate Defender for Cloud Apps and Defender for Endpoint.
Use the W365 Cloud PC only for administrative tasks—no personal browsing, no email.

Use case:
Global administrators use managed, persistent Cloud PCs to handle Azure and Microsoft 365 duties in isolation. The environment remains fully under corporate management and auditable.

3. Reference Architecture – Privileged Access Flow

This architecture ensures administrators operate only within trusted, monitored environments. All privileged sessions are logged to Sentinel, enforced with Conditional Access, and segregated from unprivileged workstations.

Real-World Impact

Over-privileged accounts are the fast track to compromise.
Attackers hunt for admin credentials because they unlock persistence, lateral movement, and data access.

By restricting admin privileges:

You reduce privilege escalation vectors
Limit malware impact scope
Create audit visibility for policy compliance
Establish a clean separation between admin and user functions

In short, it’s like locking the keg fridge—you control who pours, when, and how much.

Implementation Examples

Azure Portal – Privileged Identity Management Setup (for AVD)

Navigate to Entra ID > Privileged Identity Management
Select Azure resources > Assignments
Choose + Add assignments
Pick a role like Virtual Machine Administrator Login
Select eligible users or groups
Set assignment type to Eligible, and define Approval and Justification requirements
Configure Activation Duration (e.g., 4 hours per request)
Add Access Review policies for 12-month revalidation and automatic removal of inactive assignments after 45 days
Review and assign

Gotchas & Edge Cases

Break-glass accounts: Maintain at least one non-PIM local admin for emergency recovery, but secure its credentials in Azure Key Vault or a password vault. Use long, unique, and unpredictable passwords and log all usage.
Third-party management tools: Agents may need service accounts with consistent privileges—scope them tightly and disable interactive logon.
W365 Pro vs Enterprise: Privilege controls differ; Enterprise integrates with Intune and PIM, while Pro relies more on local settings.
Session Host recreation: Admin changes made manually on ephemeral hosts won’t persist—use automation or policy-based config instead.
Privileged account internet use: Block web and email access using Conditional Access or Endpoint Security baselines.

Best Practices

Separate user and admin identities
Implement just-in-time (JIT) privileged access using PIM
Apply least privilege RBAC at subscription and resource group levels
Automate group membership, access reviews, and logging
Enforce expiry of inactive privileged roles after 45 days
Revalidate all privileged assignments at least every 12 months
Route all audit and PIM logs to Microsoft Sentinel or immutable storage
Deny internet and email access for privileged accounts
Use AVD or W365 PAWs for all privileged administration
Always enable multi-factor authentication (MFA) for privileged operations
Integrate privileged detections into your incident response plan

Compliance Tip – Meeting ML2 Requirements

To align fully with Essential 8 Maturity Level 2:

Configure PIM policies for automatic expiry (≤45 days inactivity) and annual revalidation
Prohibit privileged accounts from internet, email, or personal app access
Store and manage break-glass credentials securely in a password or key vault
Forward all Entra ID, Intune, and Defender logs to Microsoft Sentinel with immutable retention
Monitor for privileged role changes, logon anomalies, and inactive assignments
Ensure incident response processes are triggered by privileged anomalies

These fine-tuning steps transform a good design into a fully compliant ML2 implementation.

🍺

Brewed Insight: Restricting admin rights isn’t about locking people out—it’s about serving access responsibly.
Think of AVD Admin Pools as temporary tasting paddles—you get just what you need for one session and then hand the glass back.
W365 PAWs, on the other hand, are your dedicated tap at the bar—always managed, always ready, and just for you.
Balance them properly, and you’ll pour privileged access safely without over-serving risk.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Multi‑Factor Authentication

Tue, 21 Oct 2025 00:00:00 +1100

You wouldn’t serve a flat white with instant coffee granules. So why trust a single password to protect your cloud desktops? Multi‑Factor Authentication (MFA) is the second shot your security posture needs. It takes that weak, often reused password and tops it up with something the bad actors can’t easily steal, something you have or are.

Whether your users connect to Azure Virtual Desktop (AVD), Windows 365, M365 Services or third‑party SaaS apps, MFA keeps every session secure without making sign‑ins unbearable. Think of it as your bouncer at the café door checking ID before anyone grabs a seat.

What is Multi‑Factor Authentication?

Under the Essential Eight Maturity Model Level 2 (ML2), the purpose of MFA is to stop a compromise of any single factor, like a password, from leading straight to a breach.

MFA requires two or more of the following:

Something you know: password or PIN
Something you have: phone, passkey, or hardware token
Something you are: fingerprint or facial recognition

At Level 2, MFA must be enforced for:

All users (privileged and unprivileged) accessing any online services that process sensitive data
All third‑party or SaaS platforms federated through your identity platform
Internet‑facing remote access and VDI environments like AVD and Windows 365
Authentication of all privileged accounts
Any sign‑ins that must be phishing‑resistant
MFA events logged, secured, and analysed

How it Works in Cloud VDI

Both Azure Virtual Desktop and Windows 365 authenticate through Microsoft Entra ID (Azure AD). MFA enforcement sits within Entra’s Conditional Access framework, applied consistently across Microsoft 365 and federated third‑party services.

Azure Virtual Desktop

When a user signs in through the AVD client or browser, credentials first pass through Entra ID. Conditional Access evaluates user, device, and location, and won’t issue a session token until MFA is satisfied.

Windows 365 (Cloud PC)

Identical logic applies here. The sign‑in prompt is evaluated by Entra ID before the Cloud PC session is launched.

Third‑Party and Customer‑Facing SaaS

Entra ID can federate external services (Salesforce, ServiceNow, GitHub Enterprise, etc.). Conditional Access policies extend to these apps automatically, giving one place to enforce phishing‑resistant MFA across all cloud assets.

flowchart TD U[User or Customer Device] --> E[Entra ID Authentication] E -->|Conditional Access Evaluation| P{MFA Required?} P -->|Yes| M[Prompt for MFA Verification] P -->|No| G[Grant Token] M -->|Verified| G G -->|Access Granted| AVD[AVD, Windows 365, or SaaS App] subgraph Logging L[Entra ID Sign‑in and Audit Logs] --> S[Microsoft Sentinel or SIEM] end

Phishing‑Resistant Options in Entra ID

No keys? No dramas. Microsoft Entra ID supports multiple passwordless, phishing‑resistant methods that satisfy Essential Eight ML2 without the need for physical FIDO2 devices (Because days of carrying around RSA tokens is gone):

Windows Hello for Business:
Uses asymmetric keys secured by the device TPM. The private key never leaves the endpoint and can only be unlocked by a local PIN or biometric, making it resistant to credential theft.
Microsoft Authenticator with Number Matching:
Adds in‑context verification — users match numbers between login prompt and Authenticator app. This blocks replay, man‑in‑the‑middle, and push‑fatigue attacks.
Entra ID Passkeys:
Based on WebAuthn, users store a cryptographic credential in their device or OS passkey manager (Windows, iOS, Android). Supports cross‑device sign‑in through the same asymmetric model as FIDO2.

Use Conditional Access → Authentication Strengths to enforce these phishing‑resistant MFA types across AVD, Windows 365, and SaaS applications. Select “Phishing‑resistant MFA” to ensure only the approved methods above are accepted.

Real‑World Impact

Passwords are the weakest brew in the pot, a little social engineering and they’re gone. MFA blocks over 99 percent of credential‑based attacks and gives solid assurance even when users are entirely remote.

For AVD and Windows 365, MFA is essential because both services are directly reachable from the internet. One weak password could hand over network‑level access.

Implementation Examples

Azure Portal: Conditional Access

Navigate to Microsoft Entra ID > Security > Conditional Access > Policies.
Select + New Policy.
Assign to All Users (including privileged and unprivileged).
Target All Cloud Apps or limit to AVD, Windows 365, and key SaaS connections.
Under Access Controls > Grant, check Require Multi‑Factor Authentication.
Under Authentication Strengths, select Phishing‑resistant MFA.
Enable and save the policy.

Centralised Logging with Microsoft Sentinel

Enable Diagnostic Settings under Entra ID > Audit Logs.
Send both Sign‑in Logs and Audit Logs to a Log Analytics Workspace linked to Sentinel.
Build analytics rules for repeated MFA denials, impossible‑travel sign‑ins, and push‑fatigue.
Forward incidents to your SOC workflow and CISO delegate for escalation.

Gotchas & Edge Cases

Legacy RDP or LDAP applications: Use Azure AD Application Proxy for pre‑auth protection or maintain documented exceptions with timeline to modernise.
Service and automation accounts: Move to Managed Identities instead of user credentials.
Customer portals: Use External ID with optional or enforced phishing‑resistant methods for customer MFA.
Log protection: Apply RBAC to audit data and enable immutable storage in Azure Monitor.

Best Practices

Enforce phishing‑resistant MFA using Authentication Strength policies.
Prefer Windows Hello for Business, Authenticator Number Matching, or Passkeys — not SMS or email codes.
Apply MFA to all connected SaaS and third‑party services federated via Entra ID.
Centralise MFA and sign‑in logs in Microsoft Sentinel for correlation.
Protect logs with immutable retention and restricted admin access.
Integrate detection with Defender for Cloud Apps for extra visibility.
Test and rehearse incident response including MFA‑related anomalies.

🍺

Brewed Insight: An MFA policy without proper phishing resistance or log analytics is like pulling a shot and forgetting the coffee grounds, motion but no flavour. Turn Conditional Access and Authentication Strengths into your coffee grinder: fine‑tuning every authentication so nothing bitter gets through.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Patch OS

Thu, 16 Oct 2025 00:00:00 +1100

Ever left milk out in the sun? You know how that ends sour, useless, and a bit embarrassing if anyone catches you. Unpatched operating systems are the same. They start smooth and reliable, but leave them a few cycles and they turn into a security liability. In a cloud-hosted desktop environment, a stale OS image is like serving last week’s brew to your end users it’s risky, inconsistent, and hard to swallow.

What is Patch Operating Systems?

This control from the ACSC Essential Eight focuses on keeping your operating systems current to reduce exposure to known vulnerabilities. For Maturity Level 2, organisations must:

Apply critical patches for internet‑facing systems within 48 hours of release.
Apply non‑critical patches for internet‑facing systems within two weeks.
Apply all OS patches for internal systems and non‑internet‑facing workloads within one month.
Regularly run automated discovery and vulnerability scans (at least fortnightly).

In short, stay current or stay vulnerable.

How it Works in Cloud VDI

Whether you’re using Azure Virtual Desktop (AVD) or Windows 365 (W365), the principle is the same: your operating system layer must be patched on a consistent and traceable schedule.

Azure Virtual Desktop

Uses golden images: a master VM image updates and redeploys downstream hosts.
Azure Update Manager (UMC) or Windows Update for Business (WUfB) handles recurring OS updates.
You test patches and rebuild host pools using automation to keep environments fresh.

Windows 365

Each Cloud PC is policy‑driven through Intune and WUfB.
Admins configure servicing channels, deferral periods, and reboot behaviour.
Updates are delivered directly from Microsoft, meaning no image rebuilds or manual patch runs.

Real-World Impact

Unpatched operating systems are one of the most common root causes of ransomware incidents. Attackers leverage public exploits faster than most teams can brew a long black. Regular, automated patching:

Reduces the attack surface and vulnerability dwell time.
Ensures consistent compliance with ACSC’s mandated timeframes.
Improves operational stability and audit readiness.

In a cloud VDI setup, patch discipline is the difference between a smooth latte and a burnt espresso.

Implementation – Meeting the Essential Eight Timeframes

To hit the Maturity Level 2 compliance bar, your patching process must be automated, repeatable, and verifiable. Azure gives you multiple ways to meet the 48‑hour, two‑week, and one‑month patch windows across AVD and W365 environments.

1. Discover and Scan Regularly

Tools:

Microsoft Defender for Servers / Endpoint — Daily OS vulnerability scanning.
Azure Update Manager (UMC) — Detects missing updates and compliance drift.
Defender External Attack Surface Management — Identifies internet‑facing assets.

Cadence:

Asset discovery: every 14 days.
Vulnerability scans: daily for internet‑facing, fortnightly for internal.

2. Internet‑Facing Session Hosts – Patch Within 48 Hours

Create a daily security‑only update schedule for any AVD session hosts tagged as internet‑facing.

Azure Portal Steps

Open Update Management Center.
Create a new update deployment schedule.
Target hosts tagged avd-role=sessionhost.
Select update classification: Security.
Set recurrence to Every 1 day.
Enable automatic reboot and email notifications for compliance verification.

Bicep Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


// Define a maintenance configuration for daily patching of a VM
// This configuration targets OS image Critical updates and specifies a maintenance window
resource DailySchedule 'Microsoft.Maintenance/maintenanceConfigurations@2023-10-01-preview' = {
 name: 'dailySchedule'
 location: resourceGroup().location
 properties: {
 maintenanceScope: 'OSImage'
 namespace: 'Microsoft.Compute'
 extensionProperties: {}
 visibility: 'Public'
 maintenanceWindow: {
 duration: 'PT4H' // 4 hours of Maintenance
 startDateTime: '2025-01-01T02:00:00Z' // Start at 2 AM Sydney Time
 recurEvery: Day // Every day
 timeZone: 'UTC+10:00' // AEST
 }
 installPatches:{
 windowsParameters:{
 classificationsToInclude:[
 'Critical'
 ]
 }
 rebootSetting: 'IfRequired'
 }
 }
}

// Apply the maintenance configuration to virtual machines with specific tags
resource tagBasedAssignment 'Microsoft.Maintenance/configurationAssignments@2023-04-01' = {
 name: 'AVD-tagBased-Critical-PatchSchedule'
 location: resourceGroup().location
 properties: {
 maintenanceConfigurationId: DailySchedule.id
 resourceId: '/subscriptions/${subscription().subscriptionId}/resourceGroups/${resourceGroup().name}' // Target the resource group
 filter: {
 tagSettings: {
 tags: {
 'avd-role': 'sessionhost'
 }
 filterOperator: 'All' // Match all specified tags
 }
 }
 }
}

This schedule comfortably achieves the critical‑within‑48‑hours mandate.

3. Internal or Non‑Internet‑Facing Hosts

For back‑end VMs and non‑internet‑facing AVD hosts:

Create a recurring deployment that includes both Critical and Security classifications.
Set frequency to every 14 days or monthly depending on risk classification.
Use tagging (e.g. patch-group=internal) to scope deployments automatically via Update Manager.

Portal Tip: Use Maintenance Configurations to enforce reboots after patching and to isolate patch windows outside business hours.

4. Windows 365 Cloud PCs – Intune Update Rings

Windows 365 handles updates through Windows Update for Business (WUfB), so compliance relies on your Intune configuration.

Steps:

In Intune, navigate to Devices > Windows > Update Rings for Windows 10 and later.
Create a new profile and set:
- Quality update deferral: 0–7 days.
- Servicing channel: Monthly Enterprise Channel.
- Deadline for installation: 2 days after availability.
- Enable auto‑restart with end‑user notice.
Assign to Cloud PC groups.

This achieves both the 48‑hour critical and two‑week non‑critical timing requirements.

5. Verification and Reporting

Validation is what separates “automated patching” from documented compliance.

Use Azure Policy: “Machines should be compliant with Update Manager”.
Review UMC Compliance Reports weekly.
Export results to Log Analytics or Power BI for evidence.
Cross‑check with Defender for Endpoint’s Weaknesses and Exposures report.

ACSC Requirement	Control Mechanism	Frequency	Verification
Internet‑facing hosts patched (critical ≤48 hrs)	Daily security‑only Update Manager schedule	Daily	Update Manager compliance logs
Internet‑facing hosts patched (non‑critical ≤14 days)	General update deployment	14 days	UMC reports
Internal hosts patched (≤1 month)	Tag‑based deployment scope	Monthly	Log Analytics reports
Vulnerability scanning	Defender and Update Manager	1–14 days	MDE dashboards

6. Image Lifecycle for AVD

flowchart TD A[Base OS Image] --> B[Apply Latest Patches in Staging] B --> C[Test Applications and GPOs] C --> D[Publish as Golden Image] D --> E[Deploy New Host Pool] E --> F[Automatic UMC Compliance and Reporting]

This ensures each AVD pool starts with a clean base image, patched hosts remain consistent, and rollback capability exists if a patch causes issues.

Gotchas & Edge Cases

Golden Image Drift: Avoid manually patching running hosts; always refresh from the updated base image.
Reboot Dependencies: Some cumulative updates don’t take effect until a restart.
Intune Sync Delay: W365 devices only check in at intervals — plan deadlines accordingly.
Testing Windows Updates: Use a staging host pool or pilot ring before mass deployment.

Best Practices

Align patch cycles with Microsoft Patch Tuesday for predictability.
Automate notification workflows using Logic Apps or Automation Runbooks.
Maintain tag‑based patch groupings (AVD‑PROD, AVDS‑UAT, W365‑TEST).
Track Compliance KPIs monthly — “mean time to patch” is an excellent internal metric.
Always verify before claiming ACSC compliance — auditors love data trails.

🍺

Brewed Insight: Patching is rarely glamorous, but it’s foundational. Think of it like regularly cleaning the group head on your espresso machine — skip it once and nobody notices, skip it twice and everything tastes off. Automate your patching, verify your cycles, and let Update Manager and Intune handle the grind for you.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Office Macros

Tue, 14 Oct 2025 00:00:00 +1100

You know that feeling when your latte art turns into a murky blob instead of a perfect rosetta? That’s what happens when macro security is ignored, it’s messy, inconsistent, and occasionally dangerous. In Microsoft Cloud VDI environments like Azure Virtual Desktop (AVD) and Windows 365, locking down Microsoft Office macros is a delicate pour. It’s about creating that balance between creativity and control — letting automation fuel productivity, but never letting a dodgy macro spill over into compromise.

What is “Configure Microsoft Office Macros”?

Under the Essential Eight, the goal of this control is simple: don’t let macros become a backdoor for malware. At Maturity Level 2, the ACSC expects you to:

Disable macros for users without a proven business requirement.
Allow only trusted or digitally signed macros.
Block macros originating from the Internet.
Prevent users from changing macro settings.
Enable macro antivirus scanning.
Block macros from making Win32 API calls.

It’s all about ensuring automation is helpful and harmless — like adding sugar, not sand, to your morning brew.

How it Works in Cloud VDI

Macro enforcement can look a little different depending on whether you’re managing session hosts in Azure Virtual Desktop or Cloud PCs in Windows 365.

Both run Microsoft 365 Apps, but the way policy is delivered differs:

AVD is generally multi‑session and device‑centric.
W365 is single‑user and identity‑centric, better suited for app policy management.

Let’s break down both flavours.

Two Ways to Pour the Policy: Device vs App

Option 1: Device Configuration Profiles (Intune or GPO)

Device‑level enforcement pushes configuration directly to the Windows environment — essentially, registry‑based policy under HKCU\Software\Policies\Microsoft\Office\16.0\Common\Security.

Best for:

AVD session hosts (multi‑user or pooled environments).
Hybrid joined or domain joined machines.
Scenarios where you need registry‑backed, “no user override allowed” enforcement.

Key Pros:

Covers all ACSC ML2 requirements, including the Win32 API block.
Macro UI fully greyed out.
Consistent across multi‑user sessions and golden images.

Caveats:

Requires periodic image or script updates in some environments.
Slightly heavier management overhead for dynamic host pools.

Option 2: App Policy for Microsoft 365 Apps (via Office Cloud Policy Service)

The newer, cloud‑based approach lets you target macro behaviour at the app level, not the Windows device.
These policies are managed through Intune under:
Apps > Policies for Microsoft 365 Apps

They flow down from the Office Cloud Policy Service (OCPS) and are applied whenever the user signs in to Microsoft 365 Apps with their Entra ID account.

Best for:

Windows 365 Cloud PCs (single‑user, fully cloud‑managed).
Azure AD‑joined user devices where policy follows the identity, not the VM.

Key Pros:

Lightweight, user‑centric management (no image rebuilds).
Follows the user if their Cloud PC is replaced or reset.
Ideal for tenant‑wide baseline enforcement.

Caveats:

Limited macro configuration scope (cannot yet block Win32 API calls).
Settings apply only while connected to Office services.
Not recommended for AVD multi‑session hosts.

Side‑by‑Side Comparison

	Device Configuration (Intune/GPO)	App Configuration (Office Cloud Policy Service)
Policy Scope	Machine / User (via registry)	User / Identity (via Office sign‑in)
Best Fit For	AVD, hybrid join, shared devices	Windows 365 Cloud PCs, user‑centric fleets
Delivery Channel	Intune MDM or Group Policy	Cloud Policy Service (OCPS)
Offline Behaviour	Enforced locally	Requires connectivity to refresh
Win32 API Block Supported	✅	❌ (not yet available)
Macro AV Scanning	✅	✅
Lockdown (user cannot change)	✅	✅ (for available settings)
Consistency across multi‑session	✅	❌

Real‑World Impact

Mismanaged macro policies are still one of the top causes of ransomware detonation and lateral‑movement campaigns.
A disciplined configuration:

Closes a major phishing vector.
Reinforces least‑privilege operations.
Creates a clean, consistent security posture across app delivery models.

For most deployments:

Use Intune Device Profiles for AVD.
Use App Policy (OCPS) for Windows 365.
Mix them if your organisation runs both — those policies happily coexist.

Implementation Examples

A. Using Intune (Device Configuration Profile)

In Intune admin center, go to Devices > Configuration Profiles > Create Profile.
Select Platform: Windows 10 and later, and Profile type: Templates > Administrative Templates.
Configure these settings under Microsoft Office 2016 (or later) > Security Settings > Trust Center:
- Disable all macros except digitally signed macros
- Block macros from running in files from the Internet
- Enable antivirus scanning of macros
- Block macros from calling Win32 API
- Prevent users from changing macro settings
Assign to device groups used for AVD session hosts or hybrid desktops.

B. Using Intune (App Policy for Microsoft 365 Apps)

In Intune admin center, go to Apps > Policies for Microsoft 365 Apps > Create Policy.
Sign in with appropriate privileges and select Configure Settings.
Under Security Settings > Macros, configure:
- Disable macros except digitally signed macros
- Block macros from the Internet
- Prevent users from changing macro settings
- (Optional) Enable macro antivirus scanning
Assign to AAD user groups (this follows the user across devices).

Note: The “Block Win32 API calls” setting is not available here. If ML2 compliance is mandatory, use the Device‑level policy alongside app policy to close that gap.

Policy Flow Diagram

Gotchas & Edge Cases

Unsigned macros in internal templates: use a corporate code‑signing certificate (via AD CS or Azure Key Vault).
Older builds of Microsoft 365 Apps: ensure you deploy to supported channels (Current Channel / Monthly Enterprise) for macro enforcement parity.
Multiple policy sources: If both OCPS and GPO apply, the most restrictive setting wins.
Local elevation: remove local admin rights on session hosts to prevent registry regression.
Trusted Locations: restrict write access; treat them like a tap locked after hours.

Best Practices

Always default to “disable except signed macros.”
Combine AV scanning + Win32 API blocking for full ML2 coverage.
Use App Policy (OCPS) where users are single‑tenant and mobility matters.
Use Device Policy where consistency and lockdown are key.
Audit macro execution and blocked events with Microsoft Defender for Endpoint.
Re‑test after Office channel upgrades; macro policy enforcement occasionally changes between builds.

🍺

Brewed Insight: Macro controls are like pulling espresso — pressure, temperature, and timing all matter. If you get one off, it either burns the shot (too restrictive for users) or lets something unwanted flow through.
Use Intune App Policy for flexibility, Device Profiles for reliability, and you’ll have a perfect balance — creamy productivity with zero bitter aftertaste.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Application Control

Thu, 09 Oct 2025 00:00:00 +1100

A stale flat white is bad, but a stale system image is worse.
In Cloud VDI, old software doesn’t just ruin the experience, it opens the door to exploitation. Whether you’re running Azure Virtual Desktop (AVD) or Windows 365, both need regular patching discipline to meet the ACSC Essential 8 “Patch Applications” Maturity Level 2 control.

These two platforms share the same goal, consistent, secure endpoints but they take different routes to get there. Think of one as an automatic coffee pod machine and the other as a hand‑crafted espresso rig. Both deliver great results when maintained right.

What is Patch Applications?

The Patch Applications control ensures vulnerabilities in applications and online services are identified and remediated quickly.
At Maturity Level 2, you must:

Perform automated vulnerability scanning at least fortnightly.
Apply critical patches or mitigations within 48 hours.
Apply non‑critical patches within two weeks.
Patch other applications (non‑core) within one month.
Remove unsupported or end‑of‑life software.

It’s essentially maintenance discipline — applied not to a coffee grinder, but to your digital workspace.

How It Works in Cloud VDI

Essential 8 doesn’t dictate the tools — only the outcome. In Azure, the methods differ depending on whether you use Windows 365 or Azure Virtual Desktop.

Windows 365 — The Managed Shot

Windows 365 Cloud PCs are managed Windows devices. Microsoft maintains the backend, leaving you responsible for OS and app patching through Intune and Microsoft Defender for Endpoint.

Key components:

Intune Update Rings: Control OS update cadence and reboots.
Defender Vulnerability Management: Provides continuous vulnerability discovery and exposure scoring, satisfying the fortnightly scan requirement.
Patch My PC Enterprise: Automates packaging and updating of third‑party applications through Intune.
Intune Compliance Policies: Detect unsupported or outdated software and remove or re‑install as needed.

Workflow:

flowchart TD A[Microsoft 365 Admin] --> B[Intune Policies] B --> C[Windows 365 Cloud PCs] C --> D[Microsoft Update Services] C --> E[Patch My PC Third-Party Updates] C --> F[Defender Vulnerability Management] F --> G[Exposure Score & Reports] G --> H[Compliance Dashboard] classDef azure fill:#007FFF,stroke:#fff,color:#fff class B,C,D,E,F,G,H azure

In practice:

Create and assign Windows Update Rings in Intune.
Integrate Patch My PC for third‑party app patching.
Monitor Defender Vulnerability Management weekly or fortnightly.
Enforce compliance by removing unsupported or legacy software.

Result: Cloud PCs stay patched and compliant with minimal admin touch — automation does the pouring.

Azure Virtual Desktop — The Barista’s Setup

In AVD, you control the infrastructure, which means patching must cover both session hosts and the golden image in the Shared Image Gallery. The modern approach uses Azure Update Manager for orchestration and Defender Vulnerability Management for assurance.

Key components:

Azure Update Manager: Native patch management in the Azure Portal; replaces legacy Automation Accounts.
Shared Image Gallery: Source of truth for golden image lifecycle.
Defender Vulnerability Management: Performs regular (at least fortnightly) scans across hosts.
Patch My PC Enterprise (optional): Publishes third‑party app updates to Intune for deployment to AVD hosts.
Azure Policy: Ensures unsupported images or workloads are detected and blocked from deployment.

Workflow:

flowchart TD A[Admin Team] --> B[Golden Image in Shared Image Gallery] B --> C[Session Host Pool] C --> D[Azure Update Manager Patch Deployment] D --> E[Microsoft Update Services] C --> F[Defender Vulnerability Management Scans] F --> G[Vulnerability Reports / Log Analytics] E --> C B --> H[Monthly Image Refresh Cycle] classDef azure fill:#007FFF,stroke:#fff,color:#fff class B,C,D,E,F,G,H azure

In practice:

Update the Golden Image: Patch the base image each month using Azure Update Manager. Include Windows updates, Microsoft 365 Apps, and common tools. Republish the image to your Shared Image Gallery.
Patch Active Session Hosts: Use Azure Update Manager schedules to keep hosts current between image cycles.
Vulnerability Visibility: Defender Vulnerability Management continuously scans sessions and reports missing patches.
Reimage Regularly: Re‑deploy session hosts from the updated image to eliminate drift.

Result: A consistent, controlled baseline — every host as reliable as a freshly cleaned group head.

Real‑World Impact

Both AVD and Windows 365 can meet all Maturity Level 2 outcomes, they just get there differently:

Platform	Responsibility	Tooling	Automation Level
Windows 365	Intune‑driven patching and app updates	Intune, Defender, Patch My PC	High (hands‑off)
Azure Virtual Desktop	Admin controls image refresh and host patch cadence	Update Manager, Defender, optional Patch My PC	Medium (hands‑on)

Either path gives you predictable patch windows, shorter vulnerability exposure, and clear audit evidence against ACSC requirements.

Implementation Examples

Windows 365 via Intune

Create Update Rings: Intune Admin Centre → Devices → Windows Update Rings → Create Policy.
Deploy Patch My PC: Synchronise supported applications to Intune and assign them to device groups.
Defender Vulnerability Management: Enable vulnerability scanning and review exposure reports fortnightly.

AVD via Azure Update Manager

Azure Portal → Azure Update Manager.
Select your AVD session host resource group or machines.
Create an update deployment schedule (weekly or monthly).
Configure update classifications (Critical and Security).
Enable reboot if required and monitor compliance in the Updates dashboard.

Example Bicep Snippet — VM Inclusion for Update Manager:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


// Define a maintenance configuration for weekly patching of a VM
// This configuration targets OS image critical & security updates and specifies a maintenance window
resource weeklySchedule 'Microsoft.Maintenance/maintenanceConfigurations@2023-10-01-preview' = {
 name: 'weeklySchedule'
 location: resourceGroup().location
 properties: {
 maintenanceScope: 'OSImage'
 namespace: 'Microsoft.Compute'
 extensionProperties: {}
 visibility: 'Public'
 maintenanceWindow: {
 duration: 'PT4H' // 4 hours of Maintenance
 startDateTime: '2024-01-01T02:00:00Z'
 recurEvery: 'P7D' // Every 7 days
 timeZone: 'UTC+10:00' // AEST
 }
 installPatches:{
 windowsParameters:{
 classificationsToInclude:[
 'Critical'
 'Security'
 ]
 }
 rebootSetting: 'IfRequired'
 }
 }
}

// Get the VM id of the AVD Gold Image Machine
resource vm 'Microsoft.Compute/virtualMachines@2021-07-01' existing = {
 name: 'avd-goldimg-01'
}

// Apply the maintenance configuration to a specific VM
resource maintenanceConfig 'Microsoft.Maintenance/configurationAssignments@2023-04-01' = {
 name: 'avdPatchSchedule'
 location: resourceGroup().location
 properties: {
 maintenanceConfigurationId: weeklySchedule.id
 resourceId: vm.id
 }
}

Gotchas & Edge Cases

Session Host Drift (AVD): Hosts patched manually or off‑cycle may deviate from the image — rebuild from the golden image regularly.
Third‑Party Apps (Both): Patch My PC covers most catalogues, but internal LOB apps still need custom packaging.
Licensing: Defender Vulnerability Management and Patch My PC require additional licensing.
Reboot Management: Coordinate reboots for AVD session hosts to avoid user disruption.

Best Practices

Scan Fortnightly: Use Defender Vulnerability Management to detect missing patches.
Automate Regularly: For W365, rely on Intune and Patch My PC; for AVD, lean on Azure Update Manager.
Refresh Monthly: Rebuild AVD golden images monthly and redeploy hosts.
Remove Unsupported Software: Detect and remove old versions through Intune or Azure Policy.
Visibility Matters: Monitor Defender exposure scores and Update Manager compliance to track posture improvement.

🍺

Brewed Insight:

For Windows 365, patching is a push‑button brew — Intune and Patch My PC handle the flow, Defender highlights the exposure, and compliance takes care of itself.

For Azure Virtual Desktop, you’re the barista. Update your golden image through Azure Update Manager, deploy it regularly, and let Defender confirm everything’s clean. It’s a little more manual but built for those who like precision control.

Different tools, same aroma — both paths deliver a smooth, ACSC Maturity Level 2‑compliant patch regime if you keep the cadence, refresh cycle, and scanning tight.

Learn More

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Application Control

Tue, 07 Oct 2025 00:00:00 +1100

Ever poured milk into your coffee only to realise it had gone off? That’s a similar kind of disappointment to what happens when unknown or malicious software sneaks into your virtual desktop environment. Application Control keeps your environment free from untrusted code—making sure only good beans go through the grinder.

In the world of Azure Virtual Desktop (AVD) and Windows 365 (W365), that means clearly defining and enforcing which applications and binaries can run. The result: stable, predictable, and secure workspaces ready for production.

What is Application Control?

Application Control is one of the Essential Eight mitigation strategies from the Australian Cyber Security Centre (ACSC).

Think of it as a virtual doorman: only pre‑approved software gets through the door, and everything else is turned away before it even gets to the bar.

Goal for Maturity Level 2

Implement centrally managed application allow‑listing across all workstations, internet‑facing servers, and cloud desktops. Policies must restrict execution of executables, installers, scripts, compiled HTML, and software libraries to an organisation‑approved set, while blocking everything else.

ML2 also requires:

Microsoft’s recommended application blocklist to be implemented.
All allow and block events to be centrally logged, analysed in a timely manner, and protected from unauthorised modification or deletion.
Cybersecurity events to be triaged, escalated to the CISO (or delegate), reported to the Australian Signals Directorate (ASD) where applicable, and managed under the organisation’s incident response plan.

Solutions meeting this level include Microsoft Defender Application Control (MDAC), AppLocker, and third‑party tools such as ThreatLocker and Huntress.

How it Works in Cloud VDI

Application Control enforces trust rules at the OS layer for AVD and W365 endpoints. Policies block execution outside approved paths, publishers, or hashes—keeping user and attacker activity under control.

Component	Common Tools	Policy Scope	Management Approach
Azure Virtual Desktop (AVD)	MDAC, AppLocker, ThreatLocker	Session hosts or golden image	Intune, Group Policy, or ThreatLocker Cloud Portal
Windows 365 (W365)	MDAC or ThreatLocker	Individual Cloud PCs	Intune Configuration Profiles or ThreatLocker Agent policies

Both AVD & W365 can leverage Microsoft Sentinel or Huntress for their centralised logging & managed SIEM requirements

Centralised Logging Flow

flowchart TD U[User connects to VDI] --> V["Virtual Desktop (AVD/W365)"] V --> App[User Launches Application] App --> P["Application Control Rules (MDAC / ThreatLocker)"] P -->|Approved| A[Run App] P -->|Denied| X[Block Execution] X --> E[Write Event to Local Event Log] E --> L["Forward to Central Log Platform (Sentinel / Huntress / Defender / SIEM)"] L --> S[Security Team Review and Incident Response]

MDAC/AppLocker logs to Microsoft‑Windows‑CodeIntegrity and AppLocker Operational event logs.
Logs can be forwarded using the Azure Monitor agent into Microsoft Sentinel, Defender for Endpoint, or a Huntress Managed SIEM instance.
ThreatLocker provides cloud‑native audit logs that can export directly to Huntress or Sentinel for SOC‑level analysis.
Once ingested, events are write‑once and immutable, satisfying ML2’s requirement for protecting logs from modification or deletion.

Real‑World Impact

Without Application Control, users or attackers can run virtually anything—from legitimate but risky admin tools to full‑blown malware.

Implementing this control delivers:

Clear separation between trusted and rogue executables.
Reduced attack surface across both pooled and personal VDI instances.
Operational consistency between session hosts and Cloud PCs.
Stronger evidence for Essential Eight ML2 compliance, with verifiable centralised logs.

Application allow‑listing also simplifies post‑incident analysis, helping teams trace root causes fast without hunting through endpoints one by one.

Implementation Examples

Intune Portal: MDAC with Central Logging

In Intune, open Endpoint security > Attack surface reduction > Application control.
Create a new Defender Application Control Policy and select Microsoft’s recommended blocklist to satisfy ASD requirements.
Assign a Starter policy (for example, “Allow Microsoft and Store‑signed apps”).
Deploy logging by:
- Installing the Azure Monitor Agent.
- Configuring diagnostic settings for CodeIntegrity and AppLocker operational logs.
- Sending events to Microsoft Sentinel, Huntress Managed SIEM, or Defender for Endpoint via secure connectivity.
Create analytic rules or detection packs to highlight blocked or unsigned executions.

Bicep Example (Log forwarding configuration concept)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


resource law 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
 name: 'law-avd-security'
 location: resourceGroup().location
}

resource diag 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
 name: 'sendAppControlLogs'
 scope: avdSessionHost
 properties: {
 workspaceId: law.id
 logs: [
 {
 category: 'AppLocker'
 enabled: true
 }
 {
 category: 'Microsoft-Windows-CodeIntegrity/Operational'
 enabled: true
 }
 ]
 }
}

ThreatLocker

Deploy ThreatLocker agents to your AVD or W365 devices.
Enable Learning Mode to baseline permitted applications.
Enforce policies after validation.
Review block events and alerts sent automatically to the ThreatLocker Portal or your connected SIEM.
Logs can stream directly to Huntress or Sentinel, where they’re retained securely with integrity controls.

Huntress Managed SIEM

If you prefer a fully managed logging backbone without owning a Sentinel workspace:

Connect your MDAC, Defender, or ThreatLocker telemetry sources using Huntress ingestion connectors.
Configure Windows Event Forwarding from VDI hosts (CodeIntegrity and AppLocker logs).
Huntress collects, normalises, and monitors events, providing SOC analysis and alerting back to your security team.
This satisfies ASD’s requirement for timely analysis and incident identification of application control events.

Gotchas & Edge Cases

Audit First: Begin with audit or learning mode before enforcement.
Unsigned Apps: Internal or custom apps must be signed or explicitly allowed.
Golden Image Sync: AVD hosts rebuilt from the master image must automatically receive updated allow‑lists and log forwarding.
Event Volume: Application control logs can grow quickly—plan retention filters.
Clarify SIEM Ownership: Whether Sentinel or Huntress, ensure someone is reviewing the dashboards; unattended logs don’t count toward ML2 “analysed in a timely manner.”

Best Practices

Apply Microsoft’s Recommended Application Blocklist in all MDAC deployments.
Continuously tune AppLocker or ThreatLocker rules based on review logs.
Forward logs to a central SIEM—choose Microsoft Sentinel if you want deep Azure integration, or Huntress Managed SIEM if you prefer a fully managed option with SOC oversight.
Confirm central SIEM stores logs immutably and monitors event integrity.
Validate rulesets annually, following policy drift reviews.
Strengthen your incident escalation workflow:
- SOC receives SIEM alerts from Sentinel or Huntress.
- Escalate confirmed cases to the CISO or delegate.
- If warranted, report to ASD and execute the active cyber incident response plan.

🍺

Brewed Insight:

If you’re leaning toward MDAC, remember it’s included with Microsoft Defender for Endpoint Plan 2 or Microsoft 365 E5 licences. For organisations already invested in the Microsoft ecosystem, it’s a great cost‑efficient choice.

ThreatLocker, meanwhile, delivers a refreshing user experience and strong hybrid coverage—though you’ll want to keep an eye on the subscription tab.

From experience, MDAC can require a little more operational caffeine, especially when patching shifts file paths or hash values. ThreatLocker smooths that out with autodetection and an intuitive portal interface.

For logging, Huntress Managed SIEM is fast becoming a practical option for teams that don’t want to run Sentinel themselves but still need SOC‑level visibility and Essential Eight log assurance. It’s like outsourcing the night shift for your café—someone’s always watching the machine so you can focus on the blend.

Whichever beans you pick, don’t skip the central logs. Running Application Control without proper, tamper‑proof event collection is like pulling espresso in the dark—you’ll smell what’s happening but never see where it overflowed.

Learn More

Microsoft Defender Application Control Overview
AppLocker Policies in Windows
ThreatLocker Official Documentation : only accessible via a portal login
Huntress Managed SIEM Overview
Microsoft Recommended Block Rules
Azure Monitor Agent Overview
Microsoft Sentinel Data Connectors
ACSC Essential Eight Maturity Model

Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Overview

Thu, 02 Oct 2025 00:00:00 +1100

If you’ve ever run a café, you know the key to success isn’t just brewing good coffee, it’s keeping the milk cold, the till locked, and the regulars happy. Azure Virtual Desktop (AVD) and Windows 365 (W365) are much the same: you’ve got to serve up a smooth, secure experience while making sure the behind-the-scenes hygiene is on point.

For Australian organisations, that hygiene is often measured by the ASD Essential 8 – a set of mitigation strategies published by the Australian Cyber Security Centre (ACSC). And while reaching Maturity Level 3 (the top shelf whiskey of compliance) is the long-term goal, most enterprises aim for Maturity Level 2 – the practical baseline where security meets operational reality with minimal user experience impact.

This series will show you how each of the eight controls can be implemented in Microsoft Cloud VDI (Azure Virtual Desktop & Windows 365).

What is the ASD Essential 8?

The Essential 8 is a cyber maturity set of controls designed to help organisations protect against common cyber threats. Each control is scored across three levels of maturity:

Level 1: Basic hygiene
Level 2: Reasonably resistant against adversaries with moderate capability
Level 3: Strong defence against more sophisticated, determined adversaries

For most businesses running AVD or W365, Level 2 is the “sweet spot” – achievable without paralysing operations or end user experience, but still significantly hardening the attack surface.

How it Works in Cloud VDI

In a cloud-hosted desktop world, applying the Essential 8 comes with nuances:

Azure Virtual Desktop (AVD):
- You’re responsible for image management, patching, and some underlying infra choices.
- More flexibility but also more operational work.
Windows 365 (W365):
- Microsoft handles more of the “plumbing”.
- You enforce Essential 8 primarily through Intune policies, M365 security, and Conditional Access.

The Essential 8 is technology-agnostic – but implementing it in these VDI environments means mapping controls to Azure-native services and Microsoft security stacks.

Real-World Impact

Getting to Maturity Level 2 in AVD/W365 isn’t just a compliance tick-box – it:

Reduces the chance of zero-day exploits wrecking your VDI environment
Aligns with government/industry compliance requirements (especially in AU sectors like health, finance, and gov suppliers)
Simplifies audits – you can confidently demonstrate mapped controls
Improves user trust; fewer disruptions from macro-based malware or admin misuse

In short: it lets you serve desktops with confidence, like a barista who knows the milk jug’s been cleaned.

Architectural View

Here’s a simple high-level view mapping Essential 8 controls with Cloud VDI layers:

flowchart TD subgraph Users["End Users"] U1["AVD Session Host"] U2["W365 Cloud PC"] end subgraph SecurityControls["Essential 8 Controls"] direction TB A["1. App Control"] B["2. Patch Apps"] C["3. Office Macros Config"] D["4. Patch OS"] E["5. MFA"] F["6. Admin Priv Restriction"] G["7. Application Hardening"] H["8. Daily Backups"] end Users --> SecurityControls SecurityControls --> AzureAD["Azure AD / Entra ID"] SecurityControls --> Intune["Intune / Endpoint Manager"] SecurityControls --> Defender["Microsoft Defender Suite"] SecurityControls --> AzureInfra["Azure Infra Services (Storage, Update Mgmt, Backup)"]

This series will step through how each control translates into tangible configurations inside AVD & W365.

Implementation Approach

We’ll take each of the eight controls and break them down like so:

What the control means in practice
How it applies to AVD and/or W365
Implementation via Azure Portal and Bicep
Gotchas & edge cases
Best practices

Gotchas & Edge Cases

Right from the outset, some challenges to keep in mind:

Shared Responsibility: W365 abstracts away VM management, but you still must configure policies to align with Essential 8.
FSLogix Dependencies (AVD): Application & OS patching interacts heavily with golden images and profile containers.
Licensing: Some controls (App Control, Advanced MFA scenarios, Defender features) require higher-tier licensing.
Operational Rhythm: Essential 8 isn’t “set and forget” – it’s about ongoing governance.
Line of Business (LoB) Apps: The only application within my test environment will be Microsoft Office 365 Apps, your LoB apps may have different requirements, capabilities, limitations and restrictions that you need to consider when applying E8 ML2.

Best Practices

Use security baselines in Intune as a quick start.
Map every Essential 8 control to a measurable outcome (e.g., “100% AVD session hosts patched within 48 hours”).
Build policy-as-code with Bicep where possible; align controls with CI/CD culture.
Pilot each control gradually – a poorly tested application control policy can stop users faster than a flat white served cold.

🍺

Brewed Insight: Essential 8 isn’t a compliance chore – it’s a survival kit. In the VDI world, controls like patching and admin restrictions matter even more because you’re scaling a single desktop configuration across hundreds of people. Mess it up, and you multiply your exposure. Nail it, and you’ve scaled security efficiency.

Learn More

Microsoft Defender for Cloud Apps vs Zscaler, Netskope, and Prisma

Tue, 30 Sep 2025 00:00:00 +1100

If you’ve been in security long enough, you know that Cloud Access Security Brokers (CASBs) have become the bouncers of the SaaS products keeping dodgy apps out, policing who gets in, and checking identities.

In this post, we’ll pit Microsoft Defender for Cloud Apps (MCAS) against three well-known rivals — Zscaler, Netskope, and Prisma (by Palo Alto Networks). Think of it as a tasting paddle: same category of brew, different flavours, and the right choice depends on your palate (and platform).

Its worth noting that this is an opinion article based on my own experience with each of the tools which I have leveraged or utilised over the past 12 months through various projects and personally labbing.

What is MCAS?

MCAS is Microsoft’s CASB offering, designed to help organisations secure SaaS, IaaS, and PaaS usage. It bridges the gap between users, cloud apps, and security policies by providing:

Visibility into shadow IT
Data protection via built-in DLP
Threat detection and anomaly monitoring
Seamless integration with Microsoft security stack (Entra, Defender XDR, Purview)

In other words: MCAS is the default bartender if you’re already in Microsoft’s pub.

How it Works

At a high level, a CASB sits between your users and cloud services, inspecting access requests, enforcing policies, and feeding telemetry back into your security tools.

Here’s a simplified view of MCAS in action with conditional access:

Here’s a simplified look at how the competitor CASBs typically work:

The Big Difference

One of the key architectural distinctions between Microsoft Defender for Cloud Apps (MCAS) and traditional CASBs like Zscaler or Netskope comes down to how they sit in the traffic flow.

Zscaler / Netskope — Proxy-Style CASBs

User traffic is routed through the vendor’s cloud (via VPN, GRE/IPsec tunnel, PAC file, or endpoint agent).
Every request to a SaaS app is inspected inline for DLP, threat protection, and access policies.
This means all session data passes through their infrastructure for inspection and enforcement.

Microsoft Defender for Cloud Apps — Identity-Driven CASB

Works hand in glove with Microsoft Entra ID Conditional Access.
During login/authentication, sessions are redirected to MCAS — where rules like DLP, block download, or watermarking can apply.
Instead of forcing all network traffic through a proxy, MCAS leverages authentication redirection at the identity layer.
The trade-off: less intrusive to the network, but typically limited to apps that support SAML/OAuth federation and Conditional Access App Control.

🍺

Brewed Insight:

Quick Takeaway

Zscaler/Netskope: “All your traffic flows through us for enforcement.”
MCAS: “We step in at authentication and handle policies without touching all traffic.”

Real-World Impact

Why does this matter? Because SaaS sprawl is real. Users spin up new cloud apps daily, and without visibility, sensitive data starts leaking like a dodgy beer tap.

MCAS Strengths:
- Native Microsoft integration (licensing, Entra, Purview, Defender XDR)
- Conditional access session controls baked directly in
- Cost advantage: bundled into Microsoft 365 E5
Competitor Edge:
- Netskope: Market leader in app coverage, broad SaaS connector library
- Zscaler: Strong secure web gateway (SWG) plus CASB integration
- Prisma: Multi-cloud monitoring and rich DLP capabilities

If you’re heavily Microsoft-centric, MCAS is convenient and affordable. But in hybrid or multi-cloud environments, Netskope or Prisma may bring stronger muscle.

Comparison Matrix

Category	MCAS	Netskope	Zscaler	Prisma
Visibility	★ Strong (M365 native, shadow IT discovery)	★ Strong	★ Strong	★ Strong
DLP	✔ Good (Purview integration)	★ Strong	✔ Good	★ Strong
Ecosystem Integration	★ Strong (Microsoft security stack)	✔ Good	✔ Good	✔ Good
Ease of SaaS Connectors	△ Weak (limited vs competitors)	★ Strong	✔ Good	★ Strong
Licensing Model	★ Strong (included in E5)	△ Weak (separate licensing)	△ Weak	△ Weak

Gotchas & Edge Cases

App Coverage: Many SaaS apps are supported out-of-the-box by competitors but need API customisation in MCAS.
User Experience: Session control policies can feel “clunky” with third-party apps.
Licensing Confusion: While MCAS is bundled in M365 E5, not every tenant realises they have it.

Best Practices

Start with discovery: map your shadow IT using MCAS and Entra sign-in logs.
Use conditional access app control strategically — not blanket, or users will revolt.
Integrate MCAS with Microsoft Sentinel for incident correlation.
Regularly review policy hits and false positives to fine-tune rules.

🍺

Brewed Insight: If you’re running Microsoft 365 and Azure, MCAS is your house brew — already on tap, nicely paired with the rest of the stack. But if your bar is multi-cloud and full of eclectic apps, you might want Netskope or Prisma on draught instead.

Learn More

Implementing Defender for Cloud Apps

Thu, 25 Sep 2025 00:00:00 +1100

Ever walked into a café, looked at the menu, and realised your team’s been ordering “secret shots” behind your back? That’s what shadow IT feels like: dozens of unsanctioned SaaS apps sneaking into your environment without an invite.

Microsoft Defender for Cloud Apps (formerly MCAS) is the tool that helps identify, govern, and secure those unauthorised lattes—sorry, apps—before they spill risk across your environment. Let’s break down how to get from discovery to enforcement in less time than it’d take to finish an espresso.

What is Defender for Cloud Apps?

Defender for Cloud Apps (MDCA) is Microsoft’s Cloud Access Security Broker (CASB). In plain terms:

It discovers SaaS applications in use (authorised and unauthorised)
It assesses the risk of those apps
It enforces access and session policies to keep data secure

Think of it as the bouncer at your cloud bar. Staff might try to sneak in through side doors (shadow IT), but MDCA checks who’s allowed in, and how they behave once they’re inside.

How it Works

At its core, Defender for Cloud Apps integrates with Entra ID and your network traffic sources (firewalls, proxies, etc.) to provide app discovery and control. Once connected, it can apply session controls and block risky behaviours in real-time.

Here’s a simple integration flow:

flowchart TD Firewall["Network Devices / Firewalls"] -->|Log Collector| MDCA[Defender for Cloud Apps] EntraID[Entra ID Conditional Access] --> MDCA MDCA --> DefenderXDR[Microsoft Defender XDR] User["Employees & Contractors"] -->|Access SaaS Apps| EntraID

Log collector: Ingests traffic data from firewalls/proxies for Shadow IT discovery
App connectors: Integrate directly with sanctioned apps like Office 365, Salesforce
Conditional Access App Control: Session-level enforcement handled via Entra ID policies
Defender XDR integration: Brings cloud app alerts into your broader security ecosystem

Real-World Impact

Why it matters:

Shadow IT visibility: Identify hundreds of unsanctioned apps your IT team never approved
Session control: Stop sensitive data from walking out the door (e.g., block downloads, enforce read-only web sessions)
OAuth app governance: Track and block dodgy third-party integrations into productivity suites
Unified defence: Tie into Defender XDR for incident correlation

In production, this translates to less guesswork and more enforceable guardrails.

Implementation Examples

Here’s how to get Defender for Cloud Apps moving in your first 30 minutes.

Portal Steps

🍺

Brewed Insight: Identify your firewall/proxy: Ensure it’s supported by MDCA (e.g., Palo Alto, Fortinet, Cisco, Check Point, Blue Coat, etc.).

Download the Log Collector: In the Defender for Cloud Apps portal, go to Cloud Discovery > Settings > Log collectors. Click + Add log collector.
Give it a name and download the Docker image and configuration file.
Deploy the Docker Container: on a server (Linux or Windows with Docker), run the Log Collector using the provided command and config file.
1

docker run -d -v /path/to/config:/config -p 514:514/udp mcr.microsoft.com/azure-cas/logcollector:latest
Replace /path/to/config with the actual path to your config file.
Configure Your Firewall/Proxy: Forward logs to the Log Collector’s IP and port (usually UDP 514 for Syslog).
Verify Log Collection: In the Defender for Cloud Apps portal, check the status of your Log Collector under Cloud Discovery > Settings > Log collectors.
Review Continuous Reports: Go to Cloud Discovery > Continuous reports. Select your Log Collector to view discovered apps, users, and traffic.

🍺

Brewed Insight: This is where you want to gain the understanding of your environment and what cloudapps are being used, you can then look to implement Conditional Access policies or firewall policies to treat them accordingly.

Bicep Snippet Example

Here’s a simple Bicep snippet to create a Conditional Access policy wired to Defender for Cloud Apps:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


resource conditionalAccessPolicy 'Microsoft.Authorization/policyAssignments@2020-09-01' = {
 name: 'CA-Policy-O365-MCAS'
 location: 'global'
 properties: {
 displayName: 'Block downloads of sensitive files from unmanaged devices'
 policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/ConditionalAccessPolicy'
 parameters: {
 policyName: {
 value: 'O365-MCAS-SessionControl'
 }
 state: {
 value: 'enabled'
 }
 conditions: {
 users: {
 includeUsers: [
 'All'
 ]
 }
 applications: {
 includeApplications: [
 'Office365'
 ]
 }
 clientAppTypes: [
 'browser'
 ]
 platforms: {
 includePlatforms: [
 'all'
 ]
 }
 }
 grantControls: {
 operator: 'OR'
 builtInControls: [
 'mcasSession'
 ]
 }
 sessionControls: {
 cloudAppSecurity: {
 cloudAppSecurityType: 'monitorOnly' // or 'blockDownloads'
 }
 }
 }
 }
}

Gotchas & Edge Cases

Log collector placement matters: If your traffic doesn’t flow through the collector, Shadow IT data will be incomplete.
Not all apps support session control: Conditional Access App Control targets specific web apps (check the official list).
Monitor mode first: Always start in “monitor only” mode before flipping to block—otherwise you risk employee revolts.
OAuth consent sprawl: Pay attention to risky OAuth apps bypassing controls via user consent.

Best Practices

Deploy log collectors in strategic choke points (central firewalls, VPN gateways)
Always configure app connectors for sanctioned SaaS, not just rely on discovery logs
Use Conditional Access policies with session controls for high-risk use cases (downloads, personal device access)
Regularly review OAuth app usage for suspicious integrations into Microsoft 365
Integrate alerts into Defender XDR or your SIEM for unified security monitoring

🍺

Brewed Insight: Enabling App Discovery without follow-through policies is like grinding beans but never making the coffee. Visibility is great, but without enforcement, you’re still handing out cappuccinos to anyone walking past your shop.

Learn More

What is a CASB and Why Does it Matter?

Tue, 23 Sep 2025 00:00:00 +1100

Imagine running a pub with no bouncer. Everyone gets in, nobody checks IDs, and sooner or later, trouble starts. In the cloud world, that’s pretty much what happens without a Cloud Access Security Broker (CASB). SaaS sprawl sneaks in, users start syncing sensitive data, and suddenly your business is exposed.

That’s where CASB solutions step in. They’re the bouncers of the SaaS scene — checking logins, enforcing rules, and escorting out the shady apps before they cause a problem.

What is a CASB?

A Cloud Access Security Broker (CASB) is a security control point that sits between your users and their cloud applications. It provides visibility, policy enforcement, and protection when cloud usage goes rogue.

Industry research usually defines CASB functions into four categories:

Visibility – Discover shadow IT (e.g. “Why is half the marketing team suddenly using Dropbox?”).
Compliance – Enable auditing and make sure cloud activities align with regulations (GDPR, ISO 27001).
Data Security – DLP-style controls, stop employees from dragging sensitive data out to personal apps.
Threat Protection – Detect compromised accounts, suspicious logins, and anomalous behaviour.

In plain English? CASBs are the in-between layer that helps enterprises safely embrace SaaS without losing their grip on security.

How it Works

CASBs can work in two primary modes:

API-based integration – Directly connects to SaaS platforms (e.g. O365, Salesforce) via APIs for deep inspection and control.
Proxy-based inspection – Inserts itself inline between user and cloud app traffic to enforce real-time controls.

Microsoft’s implementation, Defender for Cloud Apps (formerly MCAS), can do both — API connectors for sanctioned apps, and real-time enforcement via Conditional Access App Control through Entra ID.

Diagram – User to App with CASB Enforcement

flowchart LR U[User Device] -->|"Login / Session"| CA[Entra Conditional Access] CA --> MCAS["Defender for Cloud Apps (CASB)"] MCAS --> SaaS[SaaS Application]

Real-World Impact

Here’s why CASBs matter in day-to-day IT operations:

Stop Shadow IT – Uncover unsanctioned usage of Dropbox, Box, Slack etc.
Improve Governance – Ensure company data isn’t stored in dodgy regions.
Protect IP – Block exfiltration of sensitive documents.
Threat Detection – Spot logins from impossible geographies (Sydney at 9am, then London five minutes later).

For organisations racing towards SaaS-first models, a CASB isn’t “nice to have” — it’s mandatory to scale without blind spots.

Implementation Example

Allow Microsoft 365

Go to the Microsoft 365 Defender portal.
Navigate to Settings > Cloud Apps > Information Protection > Files.
Enable File Monitoring and click Save.
Connect Office 365 as an App Connector:
Go to Settings > Cloud Apps > App Connectors.
Click + Connect an app > Microsoft 365.
Select all relevant services (e.g., Azure AD sign-ins, Office 365 activities/files).
Click Connect and wait for the status to show Connected.
Navigate to Control > Policies > Session policies.
Create a policy like: “Block download of sensitive files from unmanaged devices” using filters like file sensitivity labels, device compliance, etc.

Bicep Snippet - Configure Conditional Access for Session Control (Optional)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


resource conditionalAccessPolicy 'Microsoft.Authorization/policyAssignments@2020-09-01' = {
 name: 'CA-Policy-O365-MCAS'
 location: 'global'
 properties: {
 displayName: 'Block downloads of sensitive files from unmanaged devices'
 policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/ConditionalAccessPolicy'
 parameters: {
 policyName: {
 value: 'O365-MCAS-SessionControl'
 }
 state: {
 value: 'enabled'
 }
 conditions: {
 users: {
 includeUsers: [
 'All'
 ]
 }
 applications: {
 includeApplications: [
 'Office365'
 ]
 }
 clientAppTypes: [
 'browser'
 ]
 platforms: {
 includePlatforms: [
 'all'
 ]
 }
 }
 grantControls: {
 operator: 'OR'
 builtInControls: [
 'mcasSession'
 ]
 }
 sessionControls: {
 cloudAppSecurity: {
 cloudAppSecurityType: 'monitorOnly' // or 'blockDownloads'
 }
 }
 }
 }
}

Block Dropbox

Go to the Microsoft 365 Defender portal.
Navigate to Discover > Discovered apps.
Find Dropbox: Use the search bar to locate Dropbox in the list of discovered apps.
Mark as Unsanctioned: Click the three dots next to Dropbox.
Block Access Automatically (Recommended): If you’re using Microsoft Defender for Endpoint, the unsanctioned app will be automatically blocked on enrolled devices.
Create a conditional access policy (optional) to deny / block access

Bicep Snippet – Configure Conditional Access Policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


param appid string = 'dropbox-app' // Get the application ID from EntraID

resource caPolicy 'Microsoft.Entra/conditionalAccessPolicies@2023-07-01-preview' = {
 name: 'Block-Dropbox-Downloads'
 properties: {
 displayName: 'Block unsanctioned SaaS downloads'
 state: 'enabled'
 conditions: {
 users: {
 includeGroups: [
 'All'
 ]
 }
 applications: {
 includeApplications: [
 appid
 ]
 }
 }
 grantControls: {
 builtInControls: [
 'block'
 ]
 }
 sessionControls: {
 applicationEnforcedRestrictions: {
 mode: 'enforce'
 }
 }
 }
}

Gotchas & Edge Cases

API connectors don’t cover every SaaS app. Some can only be monitored inline.
Performance overhead: Routing traffic through proxy = network latency if it’s all users + all SaaS.
Users hate change: If enforcement is too strict, expect support tickets. Scope carefully.

Best Practices

Start with discovery only → see what SaaS apps are really in use.
Connect the core sanctioned apps (M365, Salesforce, ServiceNow).
Build pilot policies with one department (e.g., Finance).
Use session controls for high-risk scenarios (BYOD, contractors).
Monitor impact before going org-wide — balance control and user experience.

🍺

Brewed Insight: “Shadow IT isn’t evil; it’s often people just trying to get their job done faster. The trick is to shine a light on it with CASB, then decide what’s genuinely dangerous versus what just needs a proper license.”

Learn More

Brewing a Secure Hub-and-Spoke in Azure - Operationalising the Secure Hub-and-Spoke

Thu, 18 Sep 2025 00:00:00 +1100

So you’ve designed it, deployed it, and secured it, now comes the unglamorous but critical part: operating it. A secure hub-and-spoke without monitoring and governance is like buying a coffee machine and never descaling it: it looks impressive, but eventually it’ll clog and let you down.

Operationalising the Hub-and-Spoke

A successful deployment needs three things in steady state:

Monitoring & Analytics
Governance & Cost Controls
Referenceable End-State Architecture

Monitoring with Azure Native Tools

You can’t secure what you can’t see. Wire in visibility from day one:

Azure Monitor — Baseline telemetry for VNets, connections, NSGs, and traffic flows.
Traffic Analytics — Analyses NSG flow logs to surface patterns, hotspots, and potential misconfigurations.
Azure Sentinel (Microsoft Sentinel) — SIEM integration for correlation, detections, and incident response. Ingest logs from Firewall, App GW WAF, VPN, and NSGs.
Workbooks & Dashboards — Don’t forget simple dashboards for the teams who need quick answers.

Governance & Cost Considerations

Security appliances don’t run on goodwill alone:

Firewall vs NVA
- Azure Firewall Premium is scalable and integrated, but NVAs may be justified for niche features (advanced user-ID, IPSec termination).
Traffic Costs
- Remember: inter‑VNet traffic via hubs incurs data processing and bandwidth charges. Don’t be surprised when east-west chatter racks up bills.
Policy Governance
- Centrally manage NSGs and Firewall Policy using Azure Policy definitions.
- Deploy guardrails for subnet creation, route changes, or direct internet exposure.

End-State Reference Architecture

At this stage, you’ve got all the ingredients in place:

graph TD Internet --> FW[Azure Firewall Premium] FW --> AGW[App Gateway + WAF v2] AGW --> WebApp["Web Spoke(s)"] FW --> Data["Data Spoke(s)"] FW --> Shared[Shared Services] Monitor[Azure Monitor/Sentinel] --> FW Monitor --> AGW Monitor --> NSGs

Everything feeds into monitoring, everything is governed by policy, and every spoke routes securely via the hub.

Checklist (End-State Readiness)

Hub contains Firewall, Gateway, Logging
Spokes use UDRs routing to Firewall
NSGs applied for subnet boundaries
App Gateway WAF fronting inbound web apps
Logs flowing to Sentinel/Log Analytics
Azure Policy applied for guardrails
Cost reviews scheduled regularly

Gotchas & Edge Cases

Log Noise — Sentinel dashboards can swamp you if you don’t tune. Get your query hygiene sorted.
Certificate Lifecycle — Between TLS inspection and AppGW listeners, be ready for cert renewal processes.
Multi‑Region Scaling — If you replicate the hub, keep Firewall Policy consistent across regions to avoid drift.

Best Practices

Bake operational logging into your IaC modules — don’t make it a manual add‑on.
Leverage Azure Policy for drift correction (e.g. enforce NSG, UDR rules).
Benchmark firewall usage costs monthly and optimise rules to avoid excess logging or unnecessary routing.
Run periodic architecture reviews — networks sprawl quickly; a neat hub-and-spoke can turn into spaghetti if left unchecked.

🍺

Brewed Insight: It’s tempting to treat hub-and-spoke as a “set and forget” — but that’s how you end up with stale beans and bitter coffee. To actually deliver value, you need ongoing monitoring, cost awareness, and policy enforcement. A well‑run hub-and-spoke is less about the tech and more about the discipline.

Learn More

Brewing a Secure Hub-and-Spoke in Azure - Azure Application Gateway

Tue, 16 Sep 2025 00:00:00 +1100

You wouldn’t ask your local barista to start pouring pints behind the pub bar. The same goes for security controls in Azure. Azure Firewall and Application Gateway WAF are both vital, but they serve different purposes. Get them confused and you’ll either overspend or under‑protect.

What is Application Gateway WAF?

Application Gateway (AppGW) is a Layer 7 load balancer with optional WAF (Web Application Firewall) capabilities. Think of it as traffic control at the HTTP/S level. The WAF inspects requests bound for web apps, protecting against OWASP Top 10 threats like SQLi and XSS.

Key features include:

Reverse proxy with SSL offload, end-to-end TLS, and SNI support
WAF in Detection or Prevention mode (based on OWASP rulesets)
HTTP header rewrites, redirects, URL-based routing
Autoscaling and zone redundancy for resilience

It doesn’t replace Azure Firewall. Instead, it complements it.

How They Differ: AppGW WAF vs Azure Firewall

Azure Firewall:
- L3–L7 controls
- East-west + north-south traffic
- TLS inspection, IDPS, Threat Intel
- Network-centric enforcement
App Gateway WAF:
- L7, application-specific inspection
- Inbound HTTP/S (north-south only)
- OWASP rule protection for web apps
- Application-centric enforcement

In short: Firewall protects networks, WAF protects apps.

Deployment Models

Two options exist, each used in production depending on needs:

Side-by-Side
- Azure Firewall secures all traffic centrally.
- Application Gateway WAF directly fronts the web apps.
- Internet → App Gateway WAF → Web App (spoke)
- Outbound/other spoke traffic → Firewall
Chained
- Azure Firewall sits in front of App Gateway.
- Firewall does ingress filtering, threat intel, TLS inspection.
- Clean traffic is then forwarded to App GW for WAF and app‑layer routing.
- Internet → Firewall → App Gateway WAF → Web App

flowchart TD Internet --> FW[Azure Firewall Premium] FW --> AGW[Application Gateway + WAF] AGW --> WebApp[Web App in Spoke VNet] FW --> SpokeDB[Other Spokes / Data Tiers]

Real-World Example

Inbound web traffic:

Users access public web apps hosted in Spoke VNets.
Azure Firewall Premium inspects TLS traffic, applies IDPS and Threat Intel checks.
Traffic is then allowed to Application Gateway WAF, which applies OWASP rules to the HTTP/S requests.
Clean, authorised traffic is then routed to backend VMs or App Service instances.

This setup marries the strength of both services, reducing blind spots.

Implementation Examples

Azure Portal Quick Steps

Deploy Azure Firewall Premium in Hub VNet.
Deploy Application Gateway (with WAF v2) into its own subnet, either in Hub or a Spoke.
Configure Firewall UDRs to steer inbound HTTP/S traffic via Firewall → AppGW → WebApp.
Enable WAF in Prevention mode with the latest OWASP ruleset.
Set App Gateway Listener with custom domain + SSL cert.

Bicep Example — App Gateway WAF v2 Skeleton

To continue on our previous post where we split things into modules we have created a few new resources in order to enable this feature set.

📂 Folder Structure (recommended)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


/bicep
 ├─ main.bicep # Entry point
 ├─ modules/
 | ├─ azappgateway.bicep # Azure Application Gateway
 | ├─ azfw.bicep # Azure Firewall
 | ├─ azfwpolicy.bicep # Azure Firewall Policy
 | ├─ azfwpolicypremium.bicep # Azure Firewall Premium Policy
 | ├─ keyvault.bicep # Azure KeyVault + Managed Identity (Required for TLS Inspection)
 │ ├─ hub.bicep # Hub VNet + Firewall Subnet
 │ ├─ spoke.bicep # Spoke VNet + NSG + UDR
 │ └─ peering.bicep # Hub-Spoke peering

🔹 `main.bicep` — Root deployment updated to include additional resource changes

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// Key Vault needs another new Certificate for the Application Gateway
module keyVault './modules/keyvault.bicep' = {
 name: 'keyVaultDeployment'
 params: {
 location: location
 certName: 'AzFwTlsCert'
 certSubject: 'CN=AzFwTlsCert.brewedinthecloud.com'
 keyVaultName: 'kv-azfw-hub'
 appgwcertName: 'AppGwTlsCert' //I'm using self signed in the example
 }
}

// Deploy Azure Application Gateway
module appGateway './modules/azappgw.bicep' = {
 name: 'appGatewayDeployment'
 params: {
 location: location
 subnetNameid: hub.outputs.appgwSubnetId
 appGwName: 'appgw-hub'
 appGwPublicIPName: 'appgw-hub-publicIP'
 keyVaultId: keyVault.outputs.keyVaultId
 appGwCertName: keyVault.outputs.appgwcertName
 }
}

🔹 `modules/hub.bicep` — Our secure hub virtual network needs an additional subnet for the Application Gateway

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


resource hubVnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
 name: hubVnetName
 location: location
 properties: {
 addressSpace: {
 addressPrefixes: [hubAddressPrefix]
 }
 subnets: [
 {
 name: 'AzureFirewallSubnet'
 properties: { addressPrefix: '10.0.1.0/24' }
 }
 {
 name: 'GatewaySubnet'
 properties: { addressPrefix: '10.0.255.0/27' }
 }
 {
 name: 'SharedServices'
 properties: { addressPrefix: '10.0.2.0/24' }
 }
 {
 name: 'ApplicationGateway'
 properties: { addressPrefix: '10.0.3.0/24' }
 }
 ]
 }
}

output appgwSubnetId string = hubVnet.properties.subnets[3].id

🔹 `modules/azappgateway.bicep` — Deploy Azure Application Gateway with WAFv2

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126


param location string
param subnetNameid string
param appGwName string
param appGwPublicIPName string
param appGwCertName string
param keyVaultId string

resource appGwPublicIP 'Microsoft.Network/publicIPAddresses@2023-05-01' = {
 name: appGwPublicIPName
 location: location
 sku: {
 name: 'Standard'
 tier: 'Regional'
 }
}

resource appgwwafpolicy 'Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies@2024-07-01' = {
 name: '${appGwName}-wafpolicy'
 location: location
 properties: {
 policySettings: {
 enabledState: 'Enabled'
 mode: 'Prevention'
 requestBodyCheck: true
 maxRequestBodySizeInKb: 128
 fileUploadLimitInMb: 100
 exclusions: []
 }
 customRules: []
 managedRules: {
 managedRuleSets: [
 {
 ruleSetType: 'OWASP'
 ruleSetVersion: '3.2'
 ruleGroupOverrides: []
 }
 ]
 }
 }
}

resource appGw 'Microsoft.Network/applicationGateways@2023-05-01' = {
 name: appGwName
 location: location
 sku: {
 name: 'WAF_v2'
 tier: 'WAF_v2'
 capacity: 2
 }
 properties: {
 autoscaleConfiguration: {
 minCapacity: 2
 }
 gatewayIPConfigurations: [
 {
 name: 'appGwIpConfig'
 properties: {
 subnet: {
 id: subnetNameid
 }
 }
 }
 ]
 frontendIPConfigurations: [
 {
 name: 'appGwFrontendIP-port443'
 properties: {
 publicIPAddress: {
 id: appGwPublicIP.id
 }
 }
 }
 ]
 frontendPorts: [
 {
 name: 'appGwFrontendPort-443'
 properties: {
 port: 443
 }
 }
 ]
 backendAddressPools: [
 {
 name: 'appGwBackendPool'
 properties: {
 backendAddresses: [
 ]
 }
 }
 ]
 backendHttpSettingsCollection: [
 {
 name: 'appGwBackendHttpSettings'
 properties: {
 port: 80
 protocol: 'Http'
 cookieBasedAffinity: 'Disabled'
 pickHostNameFromBackendAddress: false
 requestTimeout: 20
 }
 }
 ]
 httpListeners: [
 {
 name: 'appGwHttpsListener'
 properties: {
 frontendIPConfiguration: {
 id: resourceId('Microsoft.Network/applicationGateways/frontendIPConfigurations', appGwName, 'appGwFrontendIP')
 }
 frontendPort: {
 id: resourceId('Microsoft.Network/applicationGateways/frontendPorts', appGwName, 'appGwFrontendPort')
 }
 protocol: 'Https'
 sslCertificate: {
 id: '${keyVaultId}/certificates/${appGwCertName}'
 }
 requireServerNameIndication: false
 }
 }
 ]
 firewallPolicy: {
 id: appgwwafpolicy.id
 }
 enableHttp2: true
 }
}

Gotchas & Edge Cases

App Gateway Placement — Deploy in its own subnet; don’t cram it into shared services.
Chaining Adds Latency — More security checks = more hops. Test carefully for user‑facing apps.
Certificates — Both Firewall TLS inspection and App Gateway TLS termination need managed cert lifecycle.
Costs — Running WAF + Firewall Premium together isn’t cheap. Justify with compliance or risk posture.

Best Practices

Place App Gateway close to app workloads (same region, minimal latency).
Use WAF_v2 or higher for autoscaling and zone redundancy.
Only chain Firewall + App Gateway when you need both network + app layer security on inbound flows.
Feed WAF logs into Log Analytics to correlate alerts with Firewall.

🍺

Brewed Insight: App Gateway WAF is not a general-purpose firewall. It’s a purpose-built HTTP/S filter for protecting web apps, and it plays best when paired with Azure Firewall. Call it the hops to your malt — neither alone makes a great beer, but together they give it balance.

Learn More

Brewing a Secure Hub-and-Spoke in Azure - Azure Firewall Premium

Thu, 11 Sep 2025 00:00:00 +1100

If the hub-and-spoke is the café itself, Azure Firewall Premium is the barista making sure every shot pulled (packet inspected) is clean, safe, and consistent. You can run hub‑and‑spoke without it, but would you trust your flat white to a dodgy apprentice? Exactly.

What is Azure Firewall Premium?

Azure Firewall Premium is Microsoft’s managed, cloud-native next-gen firewall service. It’s not just packet filtering; it brings in deeper traffic inspection that usually required third-party NVAs. Its main feature set includes:

TLS Inspection: Decrypt and inspect HTTPS traffic.
IDPS (Intrusion Detection & Prevention System): Detects and blocks malicious activity in both inbound (north-south) and internal (east-west) flows.
Threat Intelligence-Based Filtering: Blocks or alerts on traffic to/from known malicious IPs/domains.
Web Categories: Allows policy setting by application category (e.g. block “Gambling” in corporate networks).

How it Works

North-South Traffic (Internet ↔ Workloads)
Routes all inbound/outbound through Azure Firewall Premium. TLS inspection and IDPS help catch suspicious connections before they hit your apps.
East-West Traffic (Spoke ↔ Spoke or VNet ↔ VNet)
Use UDRs to force inter‑VNet traffic through the hub firewall. This enables inspection of internal movement (lateral traffic) and is critical for Zero Trust.
Policy Enforcement
Azure Firewall uses Firewall Policy objects (separate resource) for consistent, reusable rule configuration. Policies can be shared across multiple firewalls in different regions.

Here’s what the secure traffic flow looks like:

graph TD Internet --> FW[Azure Firewall Premium] FW --> HubVNet[Hub VNet] HubVNet --> Spoke1[Spoke VNet 1] HubVNet --> Spoke2[Spoke VNet 2] HubVNet --> Spoke3[Spoke VNet 3] Spoke1 -->|East-West| FW Spoke2 -->|East-West| FW

Real-World Impact

Think of these scenarios:

Ransomware: Malware spreads laterally between spokes. With east-west inspection enabled, the firewall can detect and block suspicious SMB traffic.
Phishing: An internal VM gets popped and tries calling a C2 (command-and-control) endpoint. Threat intelligence filtering stops the outbound connection.
Compliance: TLS inspection ensures sensitive data flows are logged and inspected, satisfying regulatory requirements.

Without these features, most orgs would need an NVA like Palo Alto, Fortinet, or Check Point. Azure Firewall Premium narrows that gap.

Implementation Examples

Azure Portal

Create a Firewall Policy (Premium).
- Enable TLS Inspection with a Key Vault certificate.
- Turn on IDPS in Alert or Alert+Block mode.
- Enable Threat Intelligence Mode (Alert or Deny).
Attach the Firewall Policy to your Azure Firewall Premium instance.
Add Application Rules (e.g. allow HTTPS, block categories).
Add Network Rules for traffic needing explicit control.

Bicep Example — Firewall Policy with TLS Inspection, IDPS & Threat Intel

To continue on our previous post where we split things into modules we have created a few new resources in order to enable this feature set.

📂 Folder Structure (recommended)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


/bicep
 ├─ main.bicep # Entry point
 ├─ modules/
 | ├─ azfw.bicep # Azure Firewall
 | ├─ azfwpolicy.bicep # Azure Firewall Policy
 | ├─ azfwpolicypremium.bicep # Azure Firewall Premium Policy
 | ├─ keyvault.bicep # Azure KeyVault + Managed Identity (Required for TLS Inspection)
 │ ├─ hub.bicep # Hub VNet + Firewall Subnet
 │ ├─ spoke.bicep # Spoke VNet + NSG + UDR
 │ └─ peering.bicep # Hub-Spoke peering

🔹 `main.bicep` — Root deployment updated

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


// Deploy Key Vault & TLS Inspection cert
module keyVault './modules/keyvault.bicep' = {
 name: 'keyVaultDeployment'
 params: {
 location: location
 certName: 'AzFwTlsCert'
 certSubject: 'CN=AzFwTlsCert.brewedinthecloud.com'
 keyVaultName: 'kv-azfw-hub'
 }
}

// Deploy Azure Firewall Premium Policy
module azfwPolicyPremium './modules/azfwpolicypremium.bicep' = {
 name: 'azfwPolicyPremiumDeployment'
 params: {
 location: location
 policyName: 'myAzureFirewallPolicyPremium'
 managedid: keyVault.outputs.managedIdentityId
 certName: keyVault.outputs.certName
 threatIntelMode: 'Alert'
 idpsMode: 'Alert'
 }
}

🔹 `modules/keyvault.bicep` — Deploy a KeyVault & Certificate for TLS Inspection

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99


@description('Name of the Key Vault')
param keyVaultName string

@description('Location of the Key Vault')
param location string = resourceGroup().location

@description('Certificate name to create in the Key Vault')
param certName string = 'AzFwTlsCert'

@description('Subject name for the self-signed certificate')
param certSubject string = 'CN=AzFwTlsCert.brewedinthecloud.com'

@description('Key Vault SKU')
param kvSku string = 'standard'

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
 name: keyVaultName
 location: location
 properties: {
 tenantId: subscription().tenantId
 sku: {
 family: 'A'
 name: kvSku
 }
 enabledForDeployment: false
 enabledForTemplateDeployment: true
 enabledForDiskEncryption: false
 }
}

resource kvCert 'Microsoft.KeyVault/vaults/certificates@2023-07-01' = {
 name: '${keyVault.name}/${certName}'
 properties: {
 secretProperties: {
 contentType: 'application/x-pkcs12'
 }
 x509CertificateProperties: {
 subject: certSubject
 validityInMonths: 12
 keyUsage: [
 'digitalSignature'
 'keyEncipherment'
 ]
 }
 keyProperties: {
 exportable: true
 keyType: 'RSA'
 keySize: 2048
 reuseKey: false
 }
 issuerParameters: {
 name: 'Self'
 }
 createMode: 'Default'
 }
 dependsOn: [
 keyVault
 ]
}

resource kvmangedid 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
 name: '${keyVault.name}-mi'
 location: location
}

resource kvAccessPolicy 'Microsoft.KeyVault/vaults/accessPolicies@2023-07-01' = {
 name: '${keyVault.name}/add'
 properties: {
 accessPolicies: [
 {
 tenantId: subscription().tenantId
 objectId: kvmangedid.properties.principalId
 permissions: {
 certificates: [
 'get'
 'list'
 ]
 secrets: [
 'get'
 'list'
 ]
 keys: [
 'get'
 'list'
 ]
 }
 }
 ]
 }
 dependsOn: [
 keyVault
 kvmangedid
 ]
}

output keyVaultId string = keyVault.id
output certSecretId string = kvCert.properties.secretId
output certName string = kvCert.name
output managedIdentityId string = kvmangedid.id

🔹 `modules/azfwpolicypremium.bicep` — Deploy a new Firewall Policy on premium Tier

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


@description('Name of the Azure Firewall Policy')
param policyName string

@description('Location of the Firewall Policy')
param location string = resourceGroup().location

@description('Object ID of the Azure Firewall managed identity (for cert access)')
param managedid string

@description('Certificate name to create in the Key Vault')
param certName string = 'AzFwTlsCert'

@description('Threat intelligence mode (Off, Alert, Deny)')
param threatIntelMode string = 'Alert'

@description('IDPS mode (Off, Alert, AlertAndBlock)')
param idpsMode string = 'Alert'

resource azfwPolicy 'Microsoft.Network/firewallPolicies@2023-11-01' = {
 name: policyName
 location: location
 properties: {
 threatIntelMode: threatIntelMode
 intrusionDetection: {
 mode: idpsMode
 }
 sku: {
 tier: 'Premium'
 }
 transportSecurity: {
 certificateAuthority: {
 keyVaultSecretId: 'https://kv-azfw-hub.vault.azure.net/secrets/${certName}'
 name: certName
 }
 }
 }
}

output policyId string = azfwPolicy.id
output policyNameOut string = azfwPolicy.name

Gotchas & Edge Cases

TLS Inspection + Certificates: You’ll need to manage a trusted root CA in Key Vault and distribute the cert to clients. Miss that and apps will break.
Performance Overhead: TLS decryption eats into throughput and adds latency. Size accordingly.
IDPS Tuning: Default signatures can be noisy. You’ll likely need to tune exclusions.
Costs: Firewall Policy Premium and TLS inspection certificate handling do add to bills. Don’t enable everything blindly.

Best Practices

Attach multiple firewalls to the same Policy for consistent management.
Start IDPS in Alert mode before jumping into block. Get a baseline, then tighten up.
Use categories where possible (e.g. block “High Risk Domains”) to reduce rule sprawl.
Instrument with Log Analytics immediately – you’ll want visibility into which inspection rules are firing.

🍺

Brewed Insight:

Azure Firewall Premium isn’t perfect — NVAs from big vendors still win on advanced integrations. But for most enterprises in Azure, especially if you’re centralising security in a hub-and-spoke, Premium gets you 80% of the way with far less operational sweat.

Your mileage? Depends on whether you need user‑identity controls and advanced VPN terminations — if not, Azure Firewall Premium is usually the better roast.

Learn More

Brewing a Secure Hub-and-Spoke in Azure - Foundations

Tue, 09 Sep 2025 00:00:00 +1100

Do you really need another hub-and-spoke analogy? Probably not, but in enterprise networking, this pattern is as reliable as your local café’s flat white. It’s structured, scalable, and when brewed with security in mind, it keeps both auditors and architects happy.

What is the Hub-and-Spoke Model?

In Azure, the hub-and-spoke network topology is a way of organising and securing workloads:

Hub: Centralised network services such as firewalls, VPNs, and shared services (DNS, logging, identity).
Spokes: Workload VNets for applications, databases, or teams.
Peering: Low-latency, high-bandwidth connections between hub and spokes. Traffic is controlled centrally.

It’s essentially the espresso machine at the heart of your café: the spokes (applications) don’t each need their own machine — they share the central hub.

Why Hub-and-Spoke Remains the Go-To

Despite newer designs like full mesh and service chaining, hub-and-spoke continues to be the enterprise default because:

Centralised security: Easier to enforce policies (firewalls, monitoring) at a single control point.
Cost management: No need to duplicate network appliances in every spoke.
Operational simplicity: North-south internet traffic routed through one perimeter.
Flexibility: Spokes can scale independently, without dragging security along for the ride.

Core Components

A secure hub-and-spoke isn’t just about wiring up VNets — it’s about aligning platform services with security design principles.

Virtual WAN vs Traditional Hub
- Traditional Hub: Build your own hub VNet with Azure Firewall, VPN Gateway, etc. High control, higher management overhead.
- Azure Virtual WAN: Microsoft-managed global transit network. Easier to scale, great for multi-region and branch connectivity, but less granular control.
Network Security Groups (NSGs)
- Used for basic subnet or NIC-level filtering. Best for east-west microsegmentation, not a replacement for a firewall.
User Defined Routes (UDRs)
- Steer traffic through security appliances (e.g. Azure Firewall in the hub).
Azure Firewall (Recommended over NVAs)
- Enterprise-grade, cloud-native firewall. Central control point for north-south and east-west flows. Goes far beyond NSGs.

🍺

Brewed Insight:

Is Azure Firewall the right solution for you? This is a question I get a lot. Azure Firewall is still a relatively young player in the next‑gen firewall space. Compared to NVAs from vendors like Palo Alto, Fortinet, or Check Point, it lacks some of the deep integrations and polish those platforms have built up over decades.

But here’s the kicker: if all you’re after is solid layer 4 and layer 7 control, centralised logging, and cloud‑native scale without heavy user-level integrations then Azure Firewall is often more than enough.

As features continue to evolve (Premium SKUs especially), the gap is closing fast. Just make sure you line up the feature set with your actual requirements before jumping in, rather than assuming “firewall is firewall”.

Security Design Principles

If you want your hub-and-spoke to hold up under scrutiny, ground it in these security concepts:

Least Privilege Networking
- Don’t rely on “allow all VNet” rules. Be deliberate with NSGs and firewall rules.
Zero Trust Alignment
- Every spoke should authenticate and authorise. Assume compromise within the network.
Segmentation
- Keep dev, test, and prod in separate spokes — and don’t forget service-level segmentation (e.g. databases isolated from front-end tiers).

Architecture Diagram

Here’s a high-level look at a secure hub-and-spoke built with Azure Firewall:

graph TD Internet --> |North-South| AzureFirewall AzureFirewall --> HubVNet[Hub VNet] HubVNet --> Spoke1[Spoke VNet 1 - App Layer] HubVNet --> Spoke2[Spoke VNet 2 - Data Layer] HubVNet --> Spoke3[Spoke VNet 3 - Shared Services] Spoke1 <--> Spoke2 Spoke1 <--> Spoke3

Implementation Examples

Azure Portal (Quick Setup)

Create Hub VNet with subnets: AzureFirewallSubnet, GatewaySubnet, SharedServices.
Deploy Azure Firewall into AzureFirewallSubnet.
Create Spoke VNets for workloads.
Peer each Spoke VNet with the Hub VNet (enable “Use remote gateway” for spoke).
Assign UDRs in spokes to route 0.0.0.0/0 to the firewall’s private IP.
Apply NSGs for subnet-level control.

Bicep Example — Hub n Spoke using Bicep Modules

I often see folks build the first hub-and-spoke through the Azure Portal for speed, then later scramble to retrofit Bicep/ARM. Don’t, set the Bicep up front. Even if you start simple, you’ll thank yourself later when you need to scale hubs to multiple regions or automate deployments for dev/test/prod.

📂 Folder Structure (recommended)

1
2
3
4
5
6
7
8


/bicep
 ├─ main.bicep # Entry point
 ├─ modules/
 | ├─ azfw.bicep # Azure Firewall
 | ├─ azfwpolicy.bicep # Azure Firewall Policy
 │ ├─ hub.bicep # Hub VNet + Firewall Subnet
 │ ├─ spoke.bicep # Spoke VNet + NSG + UDR
 │ └─ peering.bicep # Hub-Spoke peering

🔹 `main.bicep` — Root deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


param location string = resourceGroup().location

// Hub parameters
param hubVnetName string = 'hub-vnet'
param hubAddressPrefix string = '10.0.0.0/16'

// Firewall Policy parameters
param firewallpolicyName string = 'azfwpolicy-hub'

// Firewall
param firewallName string = 'azfw-hub'

// Spoke parameters
param spokeVnetName string = 'spoke-vnet1'
param spokeAddressPrefix string = '10.1.0.0/16'

// Deploy Hub
module hub './modules/hub.bicep' = {
 name: 'hubDeployment'
 params: {
 location: location
 hubVnetName: hubVnetName
 hubAddressPrefix: hubAddressPrefix
 firewallName: firewallName
 }
}

// Deploy Spoke with Route Table and NSG
module spoke './modules/spoke.bicep' = {
 name: 'spokeDeployment'
 params: {
 location: location
 spokeVnetName: spokeVnetName
 spokeAddressPrefix: spokeAddressPrefix
 firewallPrivateIp: hub.outputs.firewallPrivateIp
 }
}

// Deploy Peering
module peering './modules/peering.bicep' = {
 name: 'peeringDeployment'
 params: {
 hubVnetName: hubVnetName
 spokeVnetName: spokeVnetName
 }
}

// Deploy Azure Firewall Policy
module azfwPolicy './modules/azfwpolicy.bicep' = {
 name: 'azfwPolicyDeployment'
 params: {
 location: location
 firewallpolicyName: firewallpolicyName
 }
}

// Deploy Azure Firewall
module azfw './modules/azfw.bicep' = {
 name: 'azfwDeployment'
 params: {
 location: location
 firewallName: firewallName
 vnetName: hub.outputs.hubVnetId
 firewallPolicyId: azfwPolicy.outputs.azureFWPolicyId
 }
}

🔹 `modules/hub.bicep` — Hub + Firewall

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


param location string
param hubVnetName string
param hubAddressPrefix string
param firewallName string

resource hubVnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
 name: hubVnetName
 location: location
 properties: {
 addressSpace: {
 addressPrefixes: [hubAddressPrefix]
 }
 subnets: [
 {
 name: 'AzureFirewallSubnet'
 properties: { addressPrefix: '10.0.1.0/24' }
 }
 {
 name: 'GatewaySubnet'
 properties: { addressPrefix: '10.0.255.0/27' }
 }
 {
 name: 'SharedServices'
 properties: { addressPrefix: '10.0.2.0/24' }
 }
 ]
 }
}

resource publicIp 'Microsoft.Network/publicIPAddresses@2023-05-01' = {
 name: '${firewallName}-pip'
 location: location
 sku: {
 name: 'Standard'
 tier: 'Regional'
 }
 properties: {
 publicIPAllocationMethod: 'Static'
 }
}

resource firewall 'Microsoft.Network/azureFirewalls@2023-05-01' = {
 name: firewallName
 location: location
 properties: {
 sku: {
 name: 'AZFW_VNet'
 tier: 'Premium'
 }
 ipConfigurations: [
 {
 name: 'fwconfig'
 properties: {
 subnet: {
 id: hubVnet.properties.subnets[0].id
 }
 publicIPAddress: {
 id: publicIp.id
 }
 }
 }
 ]
 }
}

output hubVnetId string = hubVnet.id
output firewallPrivateIp string = firewall.properties.ipConfigurations[0].properties.privateIPAddress

🔹 `modules/spoke.bicep` — Spoke VNet + Subnet NSG + UDR

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96


param location string
param spokeVnetName string
param spokeAddressPrefix string
param firewallPrivateIp string

resource spokeVnet 'Microsoft.Network/virtualNetworks@2023-05-01' = {
 name: spokeVnetName
 location: location
 properties: {
 addressSpace: {
 addressPrefixes: [spokeAddressPrefix]
 }
 subnets: [
 {
 name: 'workload'
 properties: {
 addressPrefix: '10.1.1.0/24'
 }
 }
 ]
 }
}

// Route Table
resource routeTable 'Microsoft.Network/routeTables@2023-05-01' = {
 name: '${spokeVnetName}-udr'
 location: location
 properties: {
 routes: [
 {
 name: 'default-to-firewall'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: firewallPrivateIp
 }
 }
 ]
 }
}

// Update subnet with Route Table association
resource spokeSubnet 'Microsoft.Network/virtualNetworks/subnets@2023-05-01' = {
 name: '${spokeVnet.name}/workload'
 properties: {
 addressPrefix: '10.1.1.0/24'
 routeTable: {
 id: routeTable.id
 }
 }
 dependsOn: [spokeVnet]
}

// NSG with sample rules
resource spokeNsg 'Microsoft.Network/networkSecurityGroups@2023-05-01' = {
 name: '${spokeVnetName}-nsg'
 location: location
 properties: {
 securityRules: [
 {
 name: 'allow-https-out'
 properties: {
 priority: 100
 direction: 'Outbound'
 access: 'Allow'
 protocol: 'Tcp'
 sourcePortRange: '*'
 destinationPortRange: '443'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: '*'
 }
 }
 {
 name: 'deny-all-in'
 properties: {
 priority: 200
 direction: 'Inbound'
 access: 'Deny'
 protocol: '*'
 sourcePortRange: '*'
 destinationPortRange: '*'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: '*'
 }
 }
 ]
 }
}

// Associate NSG
resource subnetNsgAssoc 'Microsoft.Network/virtualNetworks/subnets/networkSecurityGroups@2023-05-01' = {
 name: '${spokeVnet.name}/workload/${spokeNsg.name}'
 properties: {}
}

output spokeVnetId string = spokeVnet.id

🔹 `modules/peering.bicep` — Hub-Spoke Peering

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


param hubVnetName string
param spokeVnetName string

resource hubVnet 'Microsoft.Network/virtualNetworks@2023-05-01' existing = {
 name: hubVnetName
}

resource spokeVnet 'Microsoft.Network/virtualNetworks@2023-05-01' existing = {
 name: spokeVnetName
}

resource hubToSpoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-05-01' = {
 name: 'hub-to-spoke'
 parent: hubVnet
 properties: {
 remoteVirtualNetwork: {
 id: spokeVnet.id
 }
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: true
 allowGatewayTransit: true
 }
}

resource spokeToHub 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-05-01' = {
 name: 'spoke-to-hub'
 parent: spokeVnet
 properties: {
 remoteVirtualNetwork: {
 id: hubVnet.id
 }
 allowVirtualNetworkAccess: true
 allowForwardedTraffic: true
 useRemoteGateways: true
 }
}

🔹 `modules/azfwpolicy.bicep` — Azure Firewall Policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92


@description('Name of the Azure Firewall Policy')
param firewallpolicyName string = 'myAzureFirewallPolicy'

@description('Location for all resources')
param location string = resourceGroup().location

@description('Azure Firewall Policy')
resource azureFWPolicy 'Microsoft.Network/firewallPolicies@2024-05-01' = {
 name: firewallpolicyName
 location: location
}

resource networkRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2022-01-01' = {
 parent: azureFWPolicy
 name: 'DefaultNetworkRuleCollectionGroup'
 properties: {
 priority: 200
 ruleCollections: [
 {
 ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
 action: {
 type: 'Allow'
 }
 name: 'AllowAllExceptHTTPandHTTPS'
 priority: 200
 rules: [
 {
 name: 'AllowAllExcept80and443'
 description: 'Allow all traffic except ports 80 and 443'
 ruleType: 'NetworkRule'
 ipProtocols: [
 'Any'
 ]
 sourceAddresses: [
 '*'
 ]
 destinationAddresses: [
 '*'
 ]
 destinationPorts: [
 '1-79'
 '81-442'
 '444-60000'
 ]
 }
 ]
 }
 ]
 }
}

resource applicationRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2022-01-01' = {
 parent: azureFWPolicy
 name: 'DefaultApplicationRuleCollectionGroup'
 properties: {
 priority: 300
 ruleCollections: [
 {
 ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
 name: 'AllowHTTPandHTTPS'
 priority: 1000
 action: {
 type: 'Allow'
 }
 rules: [
 {
 ruleType: 'ApplicationRule'
 name: 'AllowHTTPandHTTPS'
 protocols: [
 {
 protocolType: 'Http'
 port: 80
 }
 {
 protocolType: 'Https'
 port: 443
 }
 ]
 sourceAddresses: [
 '*'
 ]
 targetFqdns: [
 '*'
 ]
 }
 ]
 }
 ]
 }
}

output azureFWPolicyId string = azureFWPolicy.id

🔹 `modules/azfw.bicep` — Azure Firewall

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


param firewallName string
param location string
param vnetName string
param firewallPolicyId string

@description('Public IP Name for Azure Firewall')
param firewallPublicIPName string = '${firewallName}-publicIP'

@description('Public IP for Azure Firewall')
resource firewallPublicIP 'Microsoft.Network/publicIPAddresses@2023-05-01' = {
 name: firewallPublicIPName
 location: location
 sku: {
 name: 'Standard'
 tier: 'Regional'
 }
 properties: {
 publicIPAllocationMethod: 'Static'
 }
}

@description('Azure Firewall Resource')
resource azureFirewall 'Microsoft.Network/azureFirewalls@2023-05-01' = {
 name: firewallName
 location: location
 properties: {
 ipConfigurations: [
 {
 name: '${firewallName}-ipConfig'
 properties: {
 publicIPAddress: {
 id: firewallPublicIP.id
 }
 subnet: {
 id: resourceId('Microsoft.Network/virtualNetworks/subnets', vnetName, 'AzureFirewallSubnet')
 }
 }
 }
 ]
 firewallPolicy: {
 id: firewallPolicyId
 }
 }
}

🍺

Brewed Insight: By modularising, you’re essentially setting up a reusable “coffee recipe”. Add more spokes? Just call the spoke.bicep module with a new name and CIDR. Want multi-region? Deploy another hub.bicep and connect. Keeps deployments consistent, scalable, and way less error‑prone.

Gotchas & Edge Cases

Peering limits: Default hard caps exist; plan address ranges carefully.
DNS resolution: Centralise DNS in the hub to avoid mismatched name resolution.
Firewall costs: Premium SKU punches holes in budgets if underutilised. Scale and size properly.

Best Practices

Go cloud native first by using Azure Firewall (premium where inspection required) for hub security over third-party NVAs unless you have a feature Azure doesn’t support.
Enable Logging + Diagnostics from day one. Push Firewall, NSG, and Azure Activity logs into Log Analytics / Sentinel.
Align NSGs with segmentation — firewalls manage inter-VNet traffic, NSGs should refine subnet/application boundaries.
Plan IP ranges early to avoid re-addressing (think coffee stains on a white shirt — harder to clean up later!).

🍺

Brewed Insight: Hub-and-spoke in Azure is a classic design that’s aged surprisingly well. The trick isn’t in building it — it’s in securing it properly. Think of it like a strong flat white: the foundation is simple (espresso + milk), but small variations in execution make all the difference. In the next post, we’ll pour a deeper shot and focus on how Azure Firewall Premium becomes the real enforcer of security.

Learn More

Stirring in Services: Zero Trust for PaaS with Private Links

Thu, 04 Sep 2025 00:00:00 +1000

You’ve segmented your VNets, layered in NSGs, and rolled out Security Admin Rules. Your traffic path is tightly controlled. But what about your Azure SQL Database? Or that Storage Account full of secrets and blobs?

By default, many PaaS services in Azure are reachable over the public internet — even if you’ve got everything else segmented. That’s like leaving the sugar jar on the café counter; any passer‑by could dip into it.

Zero Trust means your services need segmentation too. And in Azure, that’s where Private Endpoints and Private Links come in.

What are Private Endpoints / Private Link?

Azure Private Endpoint: A network interface inside your VNet that maps to a PaaS resource (SQL, Storage, Key Vault, etc).
Azure Private Link: The overall service that enables PaaS resources to be accessible privately over Azure backbone instead of public endpoints.

Effectively, you’re giving your service a private address in the VNet, reachable only by authenticated traffic from trusted sources.

Why It Matters in Zero Trust

Removes public internet exposure.
Enforces least privilege by only allowing access from the segments/VNets you define.
Works seamlessly with DNS integration using Private DNS Zones.
Reduces the blast radius — compromised workloads can’t hit services unless explicitly permitted.

Real‑World Impact

Take a Storage Account that holds application data. By default:

Developers might reach it from home IPs.
The app VNet sends requests to the public endpoint.
Anyone with SAS tokens could hit it over the internet.

With Private Link in place:

Storage has a Private Endpoint in the Data VNet.
Only VNets integrated with that endpoint can reach it.
Access controlled further with NSGs and identity (Azure AD + RBAC).
DNS automatically resolves storageaccount.blob.core.windows.net → the private IP in your VNet.

Now the service sits safely inside your segmented network boundary.

Architecture Overview

flowchart TD subgraph WebVNet[Web VNet] WebVM[Web VMs] end subgraph AppVNet[App VNet] AppVM[App VMs] end subgraph DataVNet[Data VNet] SQLpe[SQL Private Endpoint] StPE[Storage Private Endpoint] KVPE[Key Vault Private Endpoint] end subgraph HubVNet[Hub VNet] AFW[Azure Firewall] Bastion[Azure Bastion] DNS[Private DNS Zone Resolver] end Internet((Internet)) Internet --> AFW AFW --> WebVM WebVM --> AppVM AppVM --> SQLpe AppVM --> StPE AppVM --> KVPE Bastion --> WebVM Bastion --> AppVM

PaaS is now pulled into the same segmentation model. All access is denied by default unless private paths are configured.

Implementation Examples

Azure Portal Steps

Navigate to your PaaS resource (e.g. Storage Account).
Under Networking, select Private Endpoint connections.
Add a new Private Endpoint in the Data VNet (or wherever your consumers live).
Associate with a Private DNS Zone (privatelink.blob.core.windows.net).
Test resolution from App VMs → traffic stays private.
Disable public network access on the resource.

Bicep Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


param location string = resourceGroup().location
param vnetrg string = 'myVnetRg'
param subnetName string = 'PrivateEndpointSubnet'
param storageAccountName string = 'mystorageacct${uniqueString(resourceGroup().id)}'

// Virtual Network
resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' existing = {
 scope: resourceGroup(vnetrg)
 name: vnetrg
}

// Storage Account
resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
 name: storageAccountName
 location: location
 sku: { name: 'Standard_LRS' }
 kind: 'StorageV2'
 properties: {
 minimumTlsVersion: 'TLS1_2'
 publicNetworkAccess: 'Disabled' // critical step
 }
}

// Private Endpoint
resource stgPe 'Microsoft.Network/privateEndpoints@2023-05-01' = {
 name: '${storageAccountName}-pe'
 location: location
 properties: {
 subnet: {
 id: '${vnet.id}/subnets/${subnetName}'
 }
 privateLinkServiceConnections: [
 {
 name: 'stgConnection'
 properties: {
 privateLinkServiceId: stg.id
 groupIds: [ 'blob' ]
 }
 }
 ]
 }
}

// Private DNS Zone
resource stgDns 'Microsoft.Network/privateDnsZones@2020-06-01' = {
 name: 'privatelink.blob.core.windows.net'
 location: 'global'
}

// Virtual Network Link
resource vnetLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01' = {
 name: 'stg-dnslink'
 parent: stgDns
 properties: {
 virtualNetwork: { id: vnet.id }
 registrationEnabled: false
 }
}

Gotchas & Edge Cases

DNS configuration: Most errors are DNS resolution issues. Make sure Private DNS Zones are linked to every relevant VNet.
Overlapping endpoints: One service → multiple VNets → you’ll need multiple Private Endpoints or central service VNet design.
Costs: Each Private Endpoint + DNS zone has a cost. Plan accordingly at scale.
Disable public access: Forgetting this leaves your service accessible two ways — which defeats the point.

Best Practices

Deploy Private Endpoints in the data tier VNet for sensitive workloads.
Use Private DNS Zones consistently across spokes.
Always disable public access once Private Endpoints are validated.
Combine with identity (Azure AD auth for SQL, Storage, Key Vault) for layered Zero Trust.
Consider centralising Private Endpoints in a “Shared Services VNet” with controlled access if scaling across subscriptions.

🍺

Brewed Insight: Private Endpoints are like keeping your beans behind the counter — only staff should have access. Leaving PaaS exposed to the internet is like putting them out on the footpath. Zero Trust means service traffic should be private, deliberate, and identity‑verified.

Learn More

Identity is the New Perimeter: Conditional Access & Network Access

Tue, 02 Sep 2025 00:00:00 +1000

In the old world, your perimeter was defined by firewalls and LANs. If you were on the corporate network, you were “trusted.” But in Azure, admins and users connect from anywhere — home Wi‑Fi, hotel lobbies, coffee shops. The traditional perimeter doesn’t hold.

Zero Trust in Azure networking means fusing who you are with what you can reach. That’s where Conditional Access (CA), Privileged Identity Management (PIM), and Just‑in‑Time (JIT) VM access come in, reshaping the perimeter around identity itself.

What is Identity‑Driven Network Access?

Microsoft’s Zero Trust mantra: never trust, always verify.

In practice:

Every network request is tied back to identity (user, service principal, managed identity).
Access is granted dynamically, based on context → user role, device compliance, location, and risk signals.
Networking and identity controls are aligned.

Instead of “allow traffic from this subnet range”, you can define:

Require MFA if sign‑in comes from outside a trusted region.
Block legacy authentication globally.
Allow only time‑bound RDP via Bastion after JIT approval.

How Identity Meets Networking in Azure

Azure Bastion + JIT VM Access
- Removes the need for open public IPs or permanent RDP/SSH access.
- Admin session flows through Bastion, authorised by JIT + Conditional Access.
- Network path only exists while the user is approved.
Conditional Access Policies (CA)
- Govern access to the Azure Portal, PowerShell, CLI, and apps.
- Can require compliant devices, enforced MFA, or block risky sign‑ins entirely.
Privileged Identity Management (PIM)
- Admin rights aren’t always‑on. Roles become “eligible,” then explicitly activated when needed, often with approval + MFA.
Private Endpoints with Identity
- PaaS workloads (e.g. Azure SQL, Storage) are reachable via Private Endpoint inside segmented VNets.
- Resource access is granted to AAD identities or Managed Identities, not IP addresses.

Real‑World Impact

Consider a medium‑sized SaaS company:

Developers occasionally need SSH access to VMs.
Ops team manages SQL daily but wants no exposure to internet endpoints.
Security demands no standing admin rights and no exposed RDP.

By combining identity controls + network controls:

Developers must request JIT VM access, session goes via Bastion, MFA enforced, and access times out automatically.
Ops team connects only to SQL over Private Endpoint and authenticates with AAD — no public access.
Security enforces global SARs from Part 2 + Conditional Access, ensuring no open doors even if creds are leaked.

Architecture Overview

flowchart TD User["User Identity (Azure AD)"] CA[Conditional Access Policies] PIM[PIM Role Activation] Bastion[Azure Bastion] VM["VM (Spoke VNet)"] SQL["(Azure SQL w/ Private Endpoint)"] AVNM[AVNM Security Admin Rules] User --> CA CA --> PIM PIM --> Bastion Bastion --> VM VM --> SQL AVNM -. blocks bad traffic .- VM AVNM -. blocks bad traffic .- SQL

Identity acts as the perimeter → access flows only when verified and approved, layered alongside segmentation.

Implementation Examples

Azure Portal Steps

Enable JIT VM Access via Microsoft Defender for Servers.
- Go to Defender for Cloud → Virtual Machines → select your VM → configure JIT.
- Define allowed ports (22/3389), allowed IPs, and max duration.
- Access requests then flow through the Azure AD approval process.
⚠️

Warning: JIT VM Access requires an active Defender for Servers plan on your subscription or resource group. Without it, you won’t see JIT in the portal.
Configure Conditional Access
- Create a policy for “Azure Management” → require MFA and compliant device.
- Block logins from high‑risk sign‑ins.
Set up PIM role eligibility
- Remove permanent Contributor/Owner permissions.
- Assign roles as “eligible” → require activation with justification and approval.
Deploy Bastion in hub VNet
- Ensure VMs live without public IPs.
- All management flows tunnel via Bastion + identity policy.

Bicep Example (Functional JIT Policy)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


param vmName string = 'MyVm'

// Existing VM reference
resource vm 'Microsoft.Compute/virtualMachines@2023-09-01' existing = {
 name: vmName
}

// Just-In-Time policy


// Just-In-Time (JIT) network access policy for the VM
resource jitPolicy 'Microsoft.Security/locations/jitNetworkAccessPolicies@2020-01-01' = {
 name: 'JITPolicyLocation/default' // always 'default' for JIT but you have to have a Location pre-defined in Azure
 kind: 'Basic'
 properties: {
 virtualMachines: [
 {
 id: vm.id
 ports: [
 {
 number: 22 // SSH
 protocol: 'TCP'
 maxRequestAccessDuration: 'PT3H' // ISO 8601 duration, here: 3 hours
 allowedSourceAddressPrefix: '*' // allow from any IP (tighten this in prod)
 }
 {
 number: 3389 // RDP
 protocol: 'TCP'
 maxRequestAccessDuration: 'PT2H' // 2 hours
 allowedSourceAddressPrefix: '*'
 }
 ]
 }
 ]
 }
}

⚠️

Warning: Remember: this resource only works if Defender for Servers is enabled on the subscription.

Gotchas & Edge Cases

Licensing dependency: JIT requires Defender for Servers — attempting to deploy without it will fail.
Watch exclusions: Always maintain at least one break‑glass account exempt from Conditional Access.
Protocol coverage: Conditional Access works at identity layers, not raw protocol layers. Use CA + Bastion + segmentation together.
Audit & logs: Track JIT requests, Bastion sessions, and PIM activations for compliance.

Best Practices

Enforce MFA everywhere, especially admin access.
Always use JIT + Bastion rather than open NSG rules for RDP/SSH.
Combine segmentation (Post 1) and AVNM baseline denies (Post 2) with identity enforcement.
Keep privileged roles “eligible” under PIM, not “always on.”
Test CA policies carefully to prevent accidental lock‑outs.

🍺

Brewed Insight: Identity really is the new firewall. Think of it as the crema on your Zero Trust espresso — without it, the brew lacks structure and protection. With it, you add a rich, consistent layer that ties networking back to “who” is asking, not just “where” they’re from.

Learn More

Least Privilege Pour: Using NSGs & AVNM Security Admin Rules

Thu, 28 Aug 2025 00:00:00 +1000

In security, “least privilege” is like espresso the right amount gives you a perfect cup, but too much or too little ruins the pour.

In Azure networking, least privilege is enforced with Network Security Groups (NSGs) for local segmentation, and Azure Virtual Network Manager (AVNM) Security Admin Rules (SARs) for consistent global enforcement. Together, they keep your environment locked down without drowning you in manual rule management.

NSGs: Your Local Filter

NSGs sit at the subnet or network interfaces and:

Filter traffic by priority, protocol, and source/destination.
Allow/deny only the flows you intend.
Form the backbone of micro segmentation.

Example:

Web NSG → allow inbound 443 from internet.
App NSG → allow inbound 443 only from Web VNet.
Data NSG → allow inbound 1433 only from App VNet.

That’s least privilege in action, but it can get messy across dozens of VNets.

Scaling with AVNM + Security Admin Rules

When you want to apply rules consistently across many VNets and regions, AVNM steps in:

Network Groups: logical collections of VNets (e.g. “All Prod”).
Security Admin Rules: policies that apply across those groups.
Precedence: SARs override NSGs — a deny at SAR level always wins.

Typical baseline SARs:

Deny inbound RDP (3389) everywhere.
Deny inbound SMB (445) everywhere.
Only allow internet HTTPS to web‑tier VNets.

This lets you enforce non‑negotiable org‑wide controls, while teams still use NSGs for local traffic shaping.

Real‑World Impact

A dev team might accidentally allow RDP inbound on a test VNet. With SARs in place, the global deny 3389 rule overrides them. You get consistent protection without having to patrol every NSG.

That mix — NSGs for segmentation, SARs for global enforcement — is what makes “least privilege” stick in large Azure estates.

Implementation Snapshot

Azure Portal

Create Network Groups (by environment).
Apply a Security Admin Config for global denies.
Validate rule enforcement alongside existing NSGs.

Bicep Example (abridged)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


// AVNM with Security Admin Rules
resource vnetMgr 'Microsoft.Network/networkManagers@2023-12-01' = {
 name: 'corp-network-manager'
 location: resourceGroup().location
 properties: {
 networkManagerScopeAccesses: ['Connectivity','SecurityAdmin']
 networkManagerScopes: { subscriptions: [subscription().id] }
 }
}

resource prodGroup 'Microsoft.Network/networkManagers/networkGroups@2023-12-01' = {
 name: 'prod-vnets'
 parent: vnetMgr
}

resource secConfig 'Microsoft.Network/networkManagers/securityAdminConfigurations@2023-12-01' = {
 name: 'baseline-sec'
 parent: vnetMgr
}

resource deny3389 'Microsoft.Network/networkManagers/securityAdminConfigurations/ruleCollections@2023-12-01' = {
 name: 'deny-rdp'
 parent: secConfig
 properties: {
 appliesToGroups: [ { networkGroupId: prodGroup.id } ]
 rules: [
 {
 name: 'Deny-RDP'
 direction: 'Inbound'
 priority: 100
 action: 'Deny'
 protocol: 'Tcp'
 destinationPort: '3389'
 source: { addressPrefix: '*' }
 destination: { addressPrefix: '*' }
 }
 ]
 }
}

Gotchas & Best Practices

SARs override NSGs — test carefully before rollout.
Scope SARs to the right VNets/regions using Network Groups.
Use NSGs for application‑specific rules, SARs for baseline “thou shalt nots”.
Pair with Azure Policy to ensure all VNets join the correct AVNM groups.

Want the Full Deep Dive?

This is the 100ml pour. If you want the full espresso shot — including detailed rule conflicts, precedence tests, and operational lessons check out my separate article:
Azure AVNM Security Admin Rules vs NSGs in the Real World

🍺

Brewed Insight: NSGs are like your pour‑over they are crafted, precise, per‑application. But AVNM SARs are the café‑wide rule: nobody gets a cup with salt in it. Use them together, and you get security that scales without losing flavour.

Learn More

Brewing the Basics: Zero Trust Networking in Azure

Tue, 26 Aug 2025 00:00:00 +1000

Back in the on‑prem days, network security was like making coffee with a single big percolator. You poured everything in, pressed a button, and assumed the end result would be drinkable. A big firewall at the edge, a DMZ for polish, and job done.

But Azure networking demands something more refined. Workloads scale elastically, PaaS services sneak into the mix, and identities wander across devices and geographies. That “one big brew” model loses flavour quickly.

This is where Zero Trust steps in. Instead of trusting the whole pot, you brew each cup individually, verifying every grain and every pour. And at the network layer, that refinement looks like segmentation: carving your infrastructure into deliberate, isolated segments where access is granted only when justified.

What is Zero Trust Networking?

Microsoft frames Zero Trust with three core ideas:

Verify explicitly → Authorise based on identity, policy, and context.
Least privilege access → Allow just enough, and only for as long as needed.
Assume breach → Design as if attackers are already inside the network.

When mapped into networking, one extra dimension gets special focus: segmentation. That means designing networks so that resources only talk to what they need, and nothing more. In other words, your SQL database shouldn’t chat to your web tier unless you’ve brewed in rules that say it can.

How it Works in Azure

A Zero Trust‑aligned Azure network typically combines:

Virtual Networks and Subnets → Provide isolation zones to enforce segmentation.
Network Security Groups (NSGs) → Control what can flow in/out of each subnet.
Azure Firewall or Firewall Policy → Centralised inspection and outbound control.
Private Link / Private Endpoints → Ensure PaaS services (SQL, Storage, Key Vault) are reachable only via trusted VNets, not the internet.
Azure Virtual Network Manager (AVNM) → Scale segmentation and security rules across environments.
Identity‑aware access → Use Just in Time (JIT), Conditional Access, Bastion integration to align network traffic to authenticated users.

Real-World Impact

Let’s say you’re running a classic 3‑tier app in Azure: Web, App, and Database. The easy (but risky) design would be to dump everything into a single flat VNet, where any tier can talk to any other without restriction. That’s perfect for attackers but painful for defenders.

By taking a Zero Trust view, you place each tier in its own spoke VNet, connect them via a secured hub, and attach NSGs to only allow the flows you intend. That design:

Prevents a compromised web VM in one spoke from freely reaching your data tier.
Enforces explicit, logged east‑west rules through the hub.
Scales cleanly with Azure Virtual Network Manager (AVNM) to apply consistent policies across many VNets.
Makes troubleshooting easier by having logs and flow records show exactly which segment boundary is passing or blocking traffic.

Architecture Overview

Here’s a high-level Zero Trust segmentation pattern in Azure:

flowchart TD subgraph HubVNet[Hub VNet] AFW[Azure Firewall] Bastion[Azure Bastion] end subgraph Spoke1[Web VNet] SubnetWeb[Web Subnet] WebVM["Web VM(s)"] NSGWeb[Web NSG] end subgraph Spoke2[App VNet] SubnetApp[App Subnet] AppVM["App VM(s)"] NSGApp[App NSG] end subgraph Spoke3[Data VNet] SQLpe[SQL Private Endpoint] NSGData[Data NSG] end Internet[(Internet)] Internet --> AFW AFW --> WebVM WebVM --> AppVM AppVM --> SQLpe Bastion --> WebVM Bastion --> AppVM

Notice each tier has its own VNet + subnet + NSG. Access is only permitted along the explicit paths (Web→App, App→SQL).

Implementation Examples

Azure Portal Steps

Create the Hub VNet
- Deploy a hub VNet that will host shared services (Azure Firewall, Bastion, DNS forwarders if needed).
Create Spoke VNets
- Web VNet → For your front‑end workloads.
- App VNet → For application logic tier.
- Data VNet → For databases, storage, or other sensitive back‑end systems.
Peering
- Peer each spoke VNet to the hub VNet (hub‑and‑spoke).
- Disable spoke‑to‑spoke direct peering to force all east‑west traffic through the hub.
Attach NSGs
- WebNSG → Allow inbound HTTPS from internet, outbound only to App VNet.
- AppNSG → Allow inbound traffic only from Web VNet, outbound only to Data VNet.
- DataNSG → Allow inbound traffic only from App VNet.
Apply Firewall Rules in Hub
- Use Azure Firewall or Firewall Policy to allow/deny specific flows (e.g., Web→App, App→DB).
- Log and monitor everything centrally from the hub.
Private Endpoints for PaaS
- Add Private Endpoints (e.g., SQL, Storage, Key Vault) inside the Data VNet.
- Ensure DNS resolution points to the private endpoint IP, not public endpoints.
Deploy Resources
- Place VMs, App Services (via VNet Integration), and databases into their respective VNets.

Result: Each tier lives in its own segmented VNet, only talks to the tier it needs, and all traffic is filtered centrally by the hub.

Bicep Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235


param location string = resourceGroup().location

// Hub VNet – shared services like Azure Firewall, Bastion, DNS
resource hubVnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'hub-vnet'
 location: location
 properties: {
 addressSpace: { addressPrefixes: ['10.0.0.0/16'] }
 subnets: [
 {
 name: 'AzureFirewallSubnet' // reserved name for firewall
 properties: { addressPrefix: '10.0.0.0/24' }
 }
 {
 name: 'BastionSubnet' // reserved name for Bastion
 properties: { addressPrefix: '10.0.1.0/27' }
 }
 ]
 }
}

// Web Tier Spoke VNet
resource webVnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'web-vnet'
 location: location
 properties: {
 addressSpace: { addressPrefixes: ['10.1.0.0/16'] }
 }
}

// App Tier Spoke VNet
resource appVnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'app-vnet'
 location: location
 properties: {
 addressSpace: { addressPrefixes: ['10.2.0.0/16'] }
 }
}

// Data Tier Spoke VNet
resource dataVnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'data-vnet'
 location: location
 properties: {
 addressSpace: { addressPrefixes: ['10.3.0.0/16'] }
 }
}

// Example NSGs for spoke segmentation
resource webNsg 'Microsoft.Network/networkSecurityGroups@2024-07-01' = {
 name: 'web-nsg'
 location: location
 properties: {
 securityRules: [
 {
 name: 'Allow-HTTPS-In'
 properties: {
 direction: 'Inbound'
 priority: 100
 access: 'Allow'
 protocol: 'Tcp'
 sourcePortRange: '*'
 destinationPortRange: '443'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: '*'
 }
 }
 {
 name: 'Allow-Out-AppVnet'
 properties: {
 direction: 'Outbound'
 priority: 200
 access: 'Allow'
 protocol: '*'
 sourcePortRange: '*'
 destinationPortRange: '*'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: appVnet.properties.addressSpace.addressPrefixes[0]
 }
 }
 ]
 }
}

resource appNsg 'Microsoft.Network/networkSecurityGroups@2024-07-01' = {
 name: 'app-nsg'
 location: location
 properties: {
 securityRules: [
 {
 name: 'Allow-In-WebVnet'
 properties: {
 direction: 'Inbound'
 priority: 100
 access: 'Allow'
 protocol: '*'
 sourcePortRange: '*'
 destinationPortRange: '*'
 sourceAddressPrefix: webVnet.properties.addressSpace.addressPrefixes[0]
 destinationAddressPrefix: '*'
 }
 }
 {
 name: 'Allow-Out-DataVnet'
 properties: {
 direction: 'Outbound'
 priority: 200
 access: 'Allow'
 protocol: '*'
 sourcePortRange: '*'
 destinationPortRange: '*'
 sourceAddressPrefix: '*'
 destinationAddressPrefix: dataVnet.properties.addressSpace.addressPrefixes[0]
 }
 }
 ]
 }
}

resource dataNsg 'Microsoft.Network/networkSecurityGroups@2024-07-01' = {
 name: 'data-nsg'
 location: location
 properties: {
 securityRules: [
 {
 name: 'Allow-In-AppVnet'
 properties: {
 direction: 'Inbound'
 priority: 100
 access: 'Allow'
 protocol: 'Tcp'
 sourcePortRange: '*'
 destinationPortRange: '1433'
 sourceAddressPrefix: appVnet.properties.addressSpace.addressPrefixes[0]
 destinationAddressPrefix: '*'
 }
 }
 ]
 }
}

// Add Subnets and Associated NSGs
resource webSubnetAndNSG 'Microsoft.Network/virtualNetworks/subnets@2024-07-01' = {
 name: 'web-subnet'
 parent: webVnet
 properties: {
 addressPrefix: '10.1.1.0/24'
 networkSecurityGroup: {
 id: webNsg.id
 }
 }
}

resource appSubnetNsgAssociation 'Microsoft.Network/virtualNetworks/subnets@2024-07-01' = {
 name: 'app-subnet'
 parent: appVnet
 properties: {
 addressPrefix: '10.2.1.0/24'
 networkSecurityGroup: {
 id: appNsg.id
 }
 }
}

resource dataSubnetNsgAssociation 'Microsoft.Network/virtualNetworks/subnets@2024-07-01' = {
 name: 'data-subnet'
 parent: dataVnet
 properties: {
 addressPrefix: '10.3.1.0/24'
 networkSecurityGroup: {
 id: dataNsg.id
 }
 }
}

// Hub-Spoke VNet Peerings
resource hubToWebPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-07-01' = {
 name: 'hub-to-web'
 parent: hubVnet
 properties: {
 remoteVirtualNetwork: { id: webVnet.id }
 allowForwardedTraffic: true
 allowVirtualNetworkAccess: true
 }
}

resource webToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-07-01' = {
 name: 'web-to-hub'
 parent: webVnet
 properties: {
 remoteVirtualNetwork: { id: hubVnet.id }
 allowForwardedTraffic: true
 allowVirtualNetworkAccess: true
 }
}

resource hubToAppPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-07-01' = {
 name: 'hub-to-app'
 parent: hubVnet
 properties: {
 remoteVirtualNetwork: { id: appVnet.id }
 allowForwardedTraffic: true
 allowVirtualNetworkAccess: true
 }
}

resource appToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-07-01' = {
 name: 'app-to-hub'
 parent: appVnet
 properties: {
 remoteVirtualNetwork: { id: hubVnet.id }
 allowForwardedTraffic: true
 allowVirtualNetworkAccess: true
 }
}

resource hubToDataPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-07-01' = {
 name: 'hub-to-data'
 parent: hubVnet
 properties: {
 remoteVirtualNetwork: { id: dataVnet.id }
 allowForwardedTraffic: true
 allowVirtualNetworkAccess: true
 }
}

resource dataToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2024-07-01' = {
 name: 'data-to-hub'
 parent: dataVnet
 properties: {
 remoteVirtualNetwork: { id: hubVnet.id }
 allowForwardedTraffic: true
 allowVirtualNetworkAccess: true
 }
}

That’s segmentation in action: each subnet is fenced off, with NSGs acting as gates.

Gotchas & Edge Cases

Flat VNets = flat risk. If you don’t segment, lateral movement gets too easy.
NSGs aren’t inspection engines — use Firewall when you need advanced filtering, FQDNs, or logging at scale.
Over‑segmentation can slow development. Strike balance: enough to contain blasts, not so much that your developers revolt.

Best Practices

Segment by function/tier (Web, App, Data) as a baseline.
Consider landing zones in an enterprise environment where segmentation often matches business units, environments or even functions.
Deny by default in every NSG.
Use AVNM to deploy and audit segmentation policies consistently across subscriptions. (Check out my blog post around AVNM Security Admin Rules in the Real World )
Combine segmentation + Private Endpoints to fully cut off internet exposure.

🍺

Brewed Insight: Think of segmentation as the espresso shot in your Zero Trust latte. Without it, you just have warm milk (a flat network with skimpy controls). But layer those shots the right way, and you build strong, structured flavour — traffic flows only where intended, and every sip is deliberate.

Learn More

NVAs & Dynamic Routing with Azure Route Server

Thu, 21 Aug 2025 00:00:00 +1000

Static routes with UDRs are great—until networks grow, routes change, and you’re updating dozens of route tables by hand at 1am on a Sunday. Enter BGP (Border Gateway Protocol), the internet’s gift to dynamic routing and Azure Route Server, which lets your NVAs speak BGP with the fabric itself.

In this post, we explore how to use Azure Route Server with NVAs to enable dynamic routing, reduce static configuration overhead, and build smarter, faster convergence into your Azure network designs.

What is Azure Route Server?

Azure Route Server is a managed service that simplifies routing between your network virtual appliances (NVAs) and Azure’s virtual network routing, using Border Gateway Protocol (BGP). It acts as a bridge between your BGP-capable NVA and Azure’s control plane.

In plain terms: it lets your NVA advertise and learn routes dynamically, without needing API access or route table edits.

Key capabilities

BGP peering between Azure and your NVA
Dynamic route updates from NVA → VNet and vice versa
No need for manual UDR updates for many routing changes
Supports active/active and active/passive appliance setups

How It Works

Basic flow:

Deploy Azure Route Server into a dedicated /27 subnet (RouteServerSubnet) in your VNet
Deploy your NVA in the same or peered VNet with BGP enabled
Configure BGP peering between Azure Route Server and your NVA (ASNs, IPs)
Routes learned by your NVA are injected into Azure’s routing fabric
Azure can also advertise “default routes” and VNet address space back to the NVA

Real-world impact

Let’s say you’re using a third-party firewall or SD-WAN appliance to control all outbound traffic.

With Azure Route Server:

The NVA advertises a 0.0.0.0/0 default route to Azure via BGP
Azure updates the route tables dynamically, no UDR required
As workloads scale, new subnets automatically follow the NVA without needing manual updates

Deploy another appliance? Adjust policy? As long as your BGP config is updated on the appliance, Azure routes follow.

Architecture Diagram

Azure Implementation

Azure Portal Steps

Deploy virtual network with /27 subnet named RouteServerSubnet
Deploy Azure Route Server into that subnet
Deploy NVA (with BGP enabled) into same VNet or peered VNet
Use CLI or Portal to configure BGP peering:
- ASN for your NVA
- NVA BGP peer IP
- Enable peerASN, peerIP, bgpPeeringEnabled
Verify routing table on VM shows NVA via dynamic route

Bicep Deployment Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


param vnetName string = 'hub-vnet'

resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' existing = {
 name: vnetName
}

resource rsSubnet 'Microsoft.Network/virtualNetworks/subnets@2023-02-01' = {
 name: 'RouteServerSubnet'
 parent: vnet
 properties: {
 addressPrefix: '10.0.1.0/26'
 }
}

resource publicIp 'Microsoft.Network/publicIPAddresses@2020-05-01' = {
 name: 'myRouteServer-pip'
 location: resourceGroup().location
 sku: {
 name: 'Standard'
 }
 properties: {
 publicIPAllocationMethod: 'Static'
 publicIPAddressVersion: 'IPv4'
 idleTimeoutInMinutes: 4
 }
}

resource RouteServer 'Microsoft.Network/virtualHubs@2020-06-01' = {
 name: 'myRouteServer'
 location: resourceGroup().location
 properties: {
 sku: 'Standard'
 }
}

resource ipconfig 'Microsoft.Network/virtualHubs/ipConfigurations@2020-06-01' = {
 name: 'myRouteServer-ipconfig'
 parent: RouteServer
 properties: {
 subnet:{
 id: rsSubnet.id
 }
 publicIPAddress: {
 id: publicIp.id
 }
 }
}

Note: Azure Route Server uses ASN 65515. Your NVA must use a different ASN.

Gotchas & Edge Cases

NVA must support BGP: Not all appliances support this out of the box—check feature sets
No UDRs with same prefixes: They’ll override BGP-learned routes. Remove conflicting UDRs where Route Server is in use
NVA failover needs BFD or control plane detection: Otherwise route withdrawal is slow
Works best within one region/VNet. Peering adds complexity to route propagation

Best Practices

Use /27 subnet for RouteServerSubnet (mandatory requirement)
Always validate route propagation using Get-AzEffectiveRouteTable or Network Watcher
Avoid static UDRs on subnets meant to follow BGP-learned routes
Monitor with Network Insights and logs from Route Server + NVA
Design for active/passive failover with route priorities or BGP communities

🍺

Brewed Insight: Route Server changes the game for Azure routing at scale. If you’re managing NVAs with growing complexity or multi-region workloads, ditching static UDRs for BGP via Route Server is like going from instant coffee to single-origin pour over: smoother, smarter, and way more flexible. That said, test failover, keep BGP simple, and document like your life depends on it.

Learn More

Next Hop, Please - Routing to Network Virtual Appliances (NVAs)

Tue, 19 Aug 2025 00:00:00 +1000

Ever wonder how to tell your packets to take the scenic route through your security stack instead of bolting straight to the internet? That’s where NVAs and Azure routing step in. Whether you’re centralising inspection or shaping network flows, understanding next hops and the power of User Defined Routes (UDRs) is what keeps your Azure environment secure and predictable.

If you missed our intro to routing and UDRs, check out Azure Route Tables 101 — Controlling Traffic in the Cloud. That post covers the basics: route types, priorities, and the ins and outs of custom routes. In this one, we’re building on that foundation — applying UDRs to route traffic through a network security stack using Network Virtual Appliances (NVAs) or Azure Firewall.

Imagine your network traffic like a fleet of delivery vans. By default, they follow GPS (system routes) and take the shortest path to the destination. But if you’ve got a checkpoint (like a firewall), you’ll want to add some signs — custom routes — to guide them through it. Welcome to routing through NVAs.

What Is an NVA?

A Network Virtual Appliance (NVA) is a virtual machine that performs network-related functions — firewalls, proxy servers, intrusion detection systems, you name it. In Azure, it’s just another VM in a subnet, except instead of serving users, it’s inspecting and controlling traffic flows.

NVAs are commonly used to:

Enforce centralised firewall policies
Inspect traffic between on-prem and cloud
Perform deep packet inspection (e.g., IDS/IPS)
Proxy internet-bound traffic for logging or threat detection

Common options include third-party firewalls like Palo Alto, Fortinet, Check Point, or even native Azure solutions like Azure Firewall, which behaves like an NVA with cloud-native benefits.

How It Works

Azure sets up system routes automatically, letting your traffic flow between subnets, VNets, on-prem, or the internet. But to redirect traffic through an NVA, you need to override those defaults using User Defined Routes (UDRs).

The key is the “next hop” type. Here’s a quick refresher:

Route Type	Behaviour
Virtual Network	Stays within the VNet
Internet	Points to the internet (default or override)
Virtual Appliance	Sends traffic to a specific IP address — like your NVA
None	Blackholes the traffic — useful for deliberate blocking

To route through an NVA:

Create a route with the destination CIDR (e.g. 0.0.0.0/0 for internet)
Set the next hop to “Virtual Appliance”
Enter the NVA’s private IP as the next hop address

This gives you full control over east-west or north-south flows.

Real-World Impact

Here’s where this setup shines:

Centralised security inspection: All traffic from spoke VNets is filtered through a single point in the hub
Forced tunnelling: Internet-bound packets must pass through an on-premises firewall or cloud-based NVA
East-West flow control: You can monitor and restrict traffic between subnets or VNets

This approach helps ensure you’re seeing and securing everything — not just trusting default paths.

Architecture: Hub-and-Spoke with Azure Firewall

Let’s say you want all traffic from spoke VMs to be inspected before heading to the internet. You place Azure Firewall in the hub and customise routing to send everything through it.

flowchart TD SpokeVM[Spoke VM] --> |"10.0.0.0/16"| SpokeSubnet[Spoke Subnet] SpokeSubnet --> |"UDR: 0.0.0.0/0 → Firewall"| AzureFirewall[Azure Firewall in Hub] AzureFirewall --> Internet[Internet] AzureFirewall --> HubVNet[Hub VNet]

Key points:

Spoke VM wants to talk to the internet (or another spoke)
UDR routes that traffic to Azure Firewall
Firewall inspects and forwards traffic accordingly

This is how you bring traditional perimeter-style security into your cloud landscape.

Azure Portal Steps

Deploy Azure Firewall (or your preferred NVA) into the hub VNet
Grab the private IP of the firewall
Create a route table:
- Prefix: 0.0.0.0/0
- Next hop type: Virtual Appliance
- Next hop IP: private IP of the firewall
Associate that route table with the subnet in your spoke VNet
Make sure IP forwarding is enabled on the NVA (not needed for Azure Firewall)
Ensure NSGs allow traffic from your source subnet to the firewall

Bicep Example

Here’s a simple Bicep snippet for the UDR setup:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


resource routeTable 'Microsoft.Network/routeTables@2022-09-01' = {
 name: 'spoke-udr'
 location: resourceGroup().location
 properties: {
 routes: [
 {
 name: 'default-to-nva'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.1.0.4' // Make sure this IP has IP forwarding enabled if it’s a custom NVA
 }
 }
 ]
 }
}

// Lookup existing VNET
resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' existing = {
 name: 'MyVNet-01'
}

// Assign the UDR to my spoke subnet
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-02-01' = {
 parent: vnet
 name: 'MySubnet-01'
 properties: {
 addressPrefix: '10.0.1.0/24'
 routeTable: {
 id: routeTable.id
 }
 }
}

Gotchas & Edge Cases

Trying to route through NVAs? Watch out for these:

IP Forwarding: NVAs (except Azure Firewall) must have IP forwarding enabled
Return Path: If return traffic skips the firewall, you’ll get asymmetric routing — and broken flows
Appliance scaling: If your NVA scales out using VMSS, routing to a single IP becomes tricky. You might need a load balancer or go with Azure Firewall’s native scaling
VPN/ER conflicts: BGP-advertised routes from on-prem can override your UDRs unless you disable route propagation

Best Practices

Use Azure Firewall if you’re going all-in on native tooling
Always enable NSG flow logs — auditability is half the value
Test routing with az network watcher topologies or diagnostics
Keep return traffic symmetric, or use Source NAT to ensure replies go back through the firewall
Tag and document route tables carefully — circular or conflicting routes cause pain

🍺

Brewed Insight: Routing to an NVA is like sending every coffee bean through the roaster before it hits your cup — it’s an extra stop, but absolutely critical for full-bodied security flavour. NVAs give you visibility, control, and compliance — but with added complexity. If you’re running at scale or want vendor-free simplicity, Azure Firewall might be the cleaner brew, but be mindful that it may not be as fully featured as your chosen NVA

Learn More

Peering into the Void — Routing with VNet Peering

Thu, 14 Aug 2025 00:00:00 +1000

Ever built a beautiful pair of Azure VNets, peered them, and then … nothing. One side can’t talk to the other. It’s like building two suburbs with no connecting roads nobody’s able to drop around for a brew.

This post is your roadmap for how routing works in VNet peering, both within a region and globally. We’ll look at how route propagation works (and where it doesn’t), plus those subtle peering settings that make the difference between smooth traffic and a silent timeout.

Whether you’re building a hub-and-spoke architecture or just linking services across VNets, this is the guide to help you avoid routing pitfalls and get your packets home safe.

What is VNet Peering?

VNet peering connects two Azure virtual networks, letting resources talk to each other over the Microsoft backbone network, fast and low-latency.

There are two flavours:

Intra-region peering (within the same Azure region)
Global VNet peering (across different regions)

Peering is non-transitive which means VNets don’t automatically route through each other so routing must be deliberate. It doesn’t involve public IP traffic, just private addressing and internal routing.

How Routing Works with VNet Peering

When VNets are peered, Azure automatically adds system routes so that each VNet can route traffic to the other’s address space.

But there’s nuance, especially when it comes to gateways, UDRs, and route propagation.

Peering Options That Matter:

Allow forwarded traffic
→ Required if traffic is coming from a third VNet, or through a NVA (like a firewall).
Use remote gateway
→ Lets a spoke VNet use the hub’s VPN/ExpressRoute Gateway.

Routing Propagation:

System routes between peered VNets are added automatically.
UDRs (User Defined Routes) override system routes as expected.
Propagation from a remote gateway works only if:
- The hub VNet has a gateway.
- The spoke peering has Use remote gateway: Enabled.
- The hub peering has Allow gateway transit: Enabled.

Real-World Use Case: Hub and Spoke Starter

You’ve got:

Hub VNet with a VPN Gateway and an Azure Firewall
Spoke VNet hosting workloads
You want spoke traffic to route via the firewall for internet or VPN for on-prem traffic

Here’s where the peering/router settings get real handy.

Implementation: Peering & Routing via Bicep

Let’s walk through Bicep templates to:

Deploy a Hub and Spoke VNet
Peer them correctly
Route spoke traffic through the firewall in the hub

Architecture Overview

graph TD subgraph Hub VNet A[FirewallSubnet] B[Azure Firewall] end subgraph Spoke VNet C[AppSubnet] end A --> B C -.-> B B --> Internet[(Internet)]

1. Define VNets

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


resource hubVnet 'Microsoft.Network/virtualNetworks@2022-07-01' = {
 name: 'hub-vnet'
 location: resourceGroup().location
 properties: {
 addressSpace: {
 addressPrefixes: ['10.0.0.0/16']
 }
 subnets: [
 {
 name: 'AzureFirewallSubnet'
 properties: {
 addressPrefix: '10.0.0.0/24'
 }
 }
 ]
 }
}

resource spokeVnet 'Microsoft.Network/virtualNetworks@2022-07-01' = {
 name: 'spoke-vnet'
 location: resourceGroup().location
 properties: {
 addressSpace: {
 addressPrefixes: ['10.1.0.0/16']
 }
 subnets: [
 {
 name: 'AppSubnet'
 properties: {
 addressPrefix: '10.1.0.0/24'
 }
 }
 ]
 }
}

2. Peer Hub ↔ Spoke

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


resource spokeToHub 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2022-07-01' = {
 name: 'spoke-to-hub'
 parent: spokeVnet
 properties: {
 remoteVirtualNetwork: {
 id: hubVnet.id
 }
 allowForwardedTraffic: true
 allowGatewayTransit: false
 useRemoteGateways: true
 }
}

resource hubToSpoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2022-07-01' = {
 name: 'hub-to-spoke'
 parent: hubVnet
 properties: {
 remoteVirtualNetwork: {
 id: spokeVnet.id
 }
 allowForwardedTraffic: true
 allowGatewayTransit: true
 useRemoteGateways: false
 }
}

3. Add Route Table in Spoke

You’ll need to push a UDR to the AppSubnet so that traffic destined for 0.0.0.0/0 routes to the Azure Firewall Private IP (assume 10.0.0.4 here).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


resource routeTable 'Microsoft.Network/routeTables@2022-07-01' = {
 name: 'spoke-udr'
 location: resourceGroup().location
 properties: {
 routes: [
 {
 name: 'default-route-to-firewall'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.0.0.4'
 }
 }
 ]
 }
}

resource subnetUpdate 'Microsoft.Network/virtualNetworks/subnets@2022-07-01' = {
 parent: spokeVnet
 name: 'AppSubnet'
 properties: {
 addressPrefix: '10.1.0.0/24'
 routeTable: {
 id: routeTable.id
 }
 }
}

Gotchas & Edge Cases

Black holes from partial peering config: If Use remote gateway is enabled on one side but Allow gateway transit is not enabled on the other, your routes won’t propagate, and the traffic goes nowhere.
UDRs always win: If you set a UDR on a subnet, it overrides any propagated system or BGP routes—even if that UDR is broken.
Global peering latency: Still fast, still private, but slightly higher latency than intra-region.
No transitive peering: If VNet A peers with B, and B with C, A can’t reach C unless directly peered.

Best Practices

Always validate both sides of a peering connection. Peering is a two-way street.
Use Allow forwarded traffic when routing via network virtual appliances or needing spoke-to-spoke via hub routes.
For hub-and-spoke with VPN/ER gateways, Enable one, Use on the other.
Document peering topologies—spaghetti peerings are hard to unravel later.

🍺

Brewed Insight: “It’s the network’s fault” is the unofficial motto of every mystery outage. Peering and routing often get set up once and forgotten, until something breaks, and traffic silently goes nowhere. The truth is, these settings are dead easy to overlook but critical to get right. Don’t assume routing will “just work” when you peer VNets, make verifying the peering config and effective routes your first step, not your last hope.

Learn More

Azure Route Tables 101 — Controlling Traffic in the Cloud

Tue, 12 Aug 2025 00:00:00 +1000

You can have the best security appliances, the cleanest IP schema, and a VNet layout that would make a CCIE weep with admiration, but if your routes aren’t right, your traffic’s not getting anywhere.

Whether you’re connecting virtual machines, segmenting workloads, or forcing traffic through inspection hops, you have to understand how Azure route tables work. And more importantly, how to override the defaults when needed.

Let’s ditch autopilot and take control of our network flows.

What Are Azure Route Tables?

Azure route tables (known in the docs as “user-defined route tables” or UDRs) are your way of telling Azure how traffic should flow within your virtual networks.

Out of the box, Azure adds a set of system routes to every subnet—these cover basic scenarios like:

Traffic within the same VNet
Internet-bound traffic
Routing to peered VNets or service endpoints

But when default isn’t enough—say you’re deploying a firewall or need to isolate traffic, you’ll define your own routes using UDRs.

How It Works

Azure performs routing at the subnet level. Each subnet can optionally be associated with a route table. Every outbound packet is evaluated against these rules in order of specificity.

Routing decision order:

User-defined routes (UDRs): Always take priority when matched.
System routes: Used when no UDR applies.

A single route table can be associated to multiple subnets, but each subnet can only have one route table.

Each route has:

Address prefix: Destination range (CIDR format)
Next hop type: Where traffic should be sent
- Virtual Appliance (e.g., firewall)
- Virtual Network Gateway
- Internet
- None (drop traffic)
- VNet Peering
Next hop IP: Required for Virtual Appliance

Sidebar: Can you assign UDRs to a NIC? You might come across older blog posts or docs mentioning that route tables can be associated directly with a network interface (NIC). That was true once—but no longer.

Real-World Impact

Let’s explore basic traffic flow scenarios.

Traffic within a VNet (default)

In a fresh VNet with two subnets:

VM in Subnet A can talk to VM in Subnet B via default system route 10.0.0.0/16 → Virtual network.

No UDRs are required. Smooth traffic. Like coffee on a Monday morning, no surprises.

VNet peering

Peered VNets auto learn each other’s address ranges.

If VNet A (10.0.0.0/16) and VNet B (10.1.0.0/16) are peered, Azure adds system routes in both directions.
Packets treat these destinations transparently, as if part of the same network fabric.

UDRs can override this behaviour if you want to insert a middlebox (like a firewall) or block access.

Force traffic through a firewall (Defined)

You can steer traffic to a firewall by creating a UDR:

Destination: 0.0.0.0/0 (assumes catching all outbound)
Next hop: Virtual Appliance
Next hop IP: Firewall IP in same subnet/VNet

Deploying this in the subnet’s route table forces outbound traffic through the firewall.

Implementation Examples

Example: Isolate a subnet from the internet

Block outbound internet access from a subnet completely.

Route Table:

1
2
3
4


Name: DenyInternet
Route:
- Address prefix: 0.0.0.0/0
 Next hop: None

Azure Portal Steps

From the Azure Portal, go to Route Tables > + Create.
Name it e.g., DenyInternet, assign it to a region and resource group.
Once created, go to Routes > + Add:
- Address prefix: 0.0.0.0/0
- Next hop type: None
Go to Subnets > Associate > Select VNet and Subnet.

Traffic from that subnet now has nowhere to go.

Bicep Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


resource routeTable 'Microsoft.Network/routeTables@2023-02-01' = {
 name: 'DenyInternet'
 location: resourceGroup().location
 properties: {
 disableBgpRoutePropagation: false
 routes: [
 {
 name: 'blockInternet'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'None'
 }
 }
 ]
 }
}

resource vnet 'Microsoft.Network/virtualNetworks@2023-02-01' existing = {
 name: 'MyVNet-01'
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-02-01' = {
 parent: vnet
 name: 'MySubnet-01'
 properties: {
 addressPrefix: '10.0.1.0/24'
 routeTable: {
 id: routeTable.id
 }
 }
}

Diagram: Routing via UDR

graph TD sub1[Subnet A] sub2[Subnet B] fw["Firewall (NVA)"] internet[Internet] sub1 -- UDR: 0.0.0.0/0 --> fw fw --> internet sub2 --> internet

In this example, only Subnet A is forced through the firewall, while Subnet B maintains default internet access.

Gotchas & Edge Cases

UDRs only affect outbound traffic from the subnet. Inbound traffic still relies on other routes and NSGs.
Service endpoints and private endpoints can interact subtly with UDRs—be mindful of forced tunnelling.
Don’t drop all routes unintentionally. Setting 0.0.0.0/0 → None blocks all egress. Great for isolation, but painful when you forget an exception for Azure services.
If using Azure Firewall, be sure to route only egress via it, unless it’s also configured for east-west subnet flows.

Best Practices

Use least routes needed—more routes mean more complexity.
Group related subnets with shared egress paths to the same route table.
When using firewalls or NVAs, make sure to apply health probes and failover logic.
Build layered security: route + NSG + Azure Firewall = defence in depth.

🍺

Brewed Insight:

The default system routes in Azure are surprisingly good—until they aren’t.
The moment you need to inspect, isolate, or redirect traffic, UDRs become essential. But with great route tables comes great responsibility. Don’t just copy/paste. Understand what traffic you’re catching and where it’s headed.

Start simple. Test in a sandbox. Then scale out your design.

Learn More

AVNM + IPAM: Finally, Centralised Address Management without the Spreadsheet

Thu, 31 Jul 2025 00:00:00 +1000

If you’ve ever inherited a half-broken Excel workbook to manage IP ranges across dozens of VNets, you already know the pain. No validation, no automation, no mercy.

Well, grab your coffee, Azure Virtual Network Manager (AVNM) just got a serious upgrade: built-in IP Address Management (IPAM).

This feature rounds out AVNM as a first-party control plane for enterprise-scale networking. Let’s get into what it is, how it works, and why it’s a game-changer.

What is AVNM IPAM?

AVNM’s IP Address Management (IPAM) is a native Azure capability for centrally managing private IP address spaces across your Virtual Networks, without flogging spreadsheets or building DIY governance layers.

Common Uses

Automating IP address assignment at scale
Preventing overlapping CIDR allocations across business units
Standardising subnet ranges within environments (e.g., non-prod, prod)
Improving visibility for audit and growth planning

Key Features

Centrally manage IP spaces within an AVNM scope
Create and assign child IP prefixes to VNets and subnets
Enforce address allocation policies to avoid overlaps
Visualise and track IP usage across regions and subscriptions
Integrate directly with VNet creation and subnet allocation

Think of it as an address ledger with guardrails — and it’s built right into the same control plane you’re (hopefully) already using for network groupings and connectivity configurations.

Architecture View

graph TD AVNM[Azure Virtual Network Manager] IPAMPool[IPAM Pool] ParentPrefix["Parent Prefix (e.g., 10.1.0.0/16)"] ChildPrefix1["Child Prefix (10.1.1.0/24)"] ChildPrefix2["Child Prefix (10.1.2.0/24)"] VNet1[VNet A] VNet2[VNet B] AVNM --> IPAMPool IPAMPool --> ParentPrefix ParentPrefix --> ChildPrefix1 --> VNet1 ParentPrefix --> ChildPrefix2 --> VNet2

How It Works

Create an IPAM Pool
This acts as a container for your IP space hierarchy. You can have one or more per AVNM.
Define Parent Prefixes
These are top-level CIDR ranges you plan to carve up (e.g. 10.0.0.0/8). These must be non-overlapping per IPAM Pool.
Allocate Child Prefixes
Carve out smaller address blocks — like 10.0.1.0/24 — from your parent prefix. These can be assigned manually to VNets or automatically through deployment tools.
Track IP Usage and Availability
IPAM gives you visibility into what’s been used, what’s free, and what’s assigned where — all within the AVNM scope.

Real-World Impact

Before IPAM, Azure customers had a few not-so-great options:

Manual IP range tracking with spreadsheets (error-prone and unscalable)
Custom solutions using Tags, Policies, or scripts (hard to maintain)
Over-architecting with CIDR guesswork to avoid future conflicts

Now with IPAM baked into AVNM:

Network teams get full control over address planning and enforcement
App teams can consume space predictably without stepping on toes
Governance and growth are no longer mutually exclusive

Implementation Examples

Let’s walk through allocating a prefix to a new VNet using Azure Portal and Bicep.

Azure Portal

Go to Azure Virtual Network Manager
Select your AVNM scope
Under IPAM, create an IPAM Pool
Add a Parent Prefix — e.g., 10.1.0.0/16
Allocate a Child Prefix — e.g., 10.1.1.0/24
When creating a new VNet, select Use IPAM and bind it to your AVNM and specific prefix

Bicep Example: Hub & Spoke with IPAM

This example sets up a Network Manager and IPAM Pool, then creates a Hub and Spoke VNet pair — each allocated dynamically from the pool.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71


@description('Location for all resources')
param location string = resourceGroup().location

@description('Name of the Network Manager')
param networkManagerName string = 'myNetworkManager'

// Create the Azure Virtual Network Manager (AVNM)
resource avnm 'Microsoft.Network/networkManagers@2024-07-01' = {
 name: networkManagerName
 location: location
 properties: {
 networkManagerScopeAccesses: ['Connectivity', 'SecurityAdmin']
 networkManagerScopes: {
 subscriptions: [subscription().id]
 }
 }
}

resource avnmIPAM 'Microsoft.Network/networkManagers/ipamPools@2024-07-01' = {
 name: 'IPAM-AUEast'
 parent: avnm
 location: location
 properties: {
 addressPrefixes: ['10.1.0.0/16']
 description: 'Parent prefix for Australia East VNets'
 }
}

// Create AU East Hub VNet and use IPAM Pool for prefix allocation
resource auEasthubVnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'MyHubVNet-AUEast'
 location: location
 properties: {
 addressSpace: {
 ipamPoolPrefixAllocations: [
 {
 pool: {
 id: avnmIPAM.id
 }
 numberOfIpAddresses: 256 // requests a /24 prefix from the IPAM Pool. Azure will automatically assign a non-overlapping block of that size.
 }
 ]
 }
 }
 tags: {
 environment: 'HubNet'
 region: 'australiaeast'
 }
}

// Create AU East Spoke VNet and use IPAM Pool for prefix allocation
resource auEastspokeVnet01 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'MySpokeVNet01-AUEast'
 location: location
 properties: {
 addressSpace: {
 ipamPoolPrefixAllocations: [
 {
 pool: {
 id: avnmIPAM.id
 }
 numberOfIpAddresses: 256 // requests a /24 prefix from the IPAM Pool. Azure will automatically assign a non-overlapping block of that size.
 }
 ]
 }
 }
 tags: {
 environment: 'production'
 region: 'australiaeast'
 }
}

Gotchas & Edge Cases

No retroactive allocations: You can only assign prefixes to VNets that opt-in to IPAM. Existing VNets without IPAM are left untouched.
Enforcement isn’t universal: IPAM doesn’t stop someone from manually typing in a bad address — yet. Policy integration is coming.
Doesn’t manage public IPs: This is strictly private address space for now.

Best Practices

Plan your hierarchy early: Define parent blocks at /16 or similar size for long-term flexibility.
One IPAM Group per environment or region: Keeps things clean and logically segmented.
Automate allocations: Use Bicep or Terraform to keep it consistent.
Enable IPAM with NetOps, not after: This isn’t a bolt-on; make it part of your standard network provisioning flow.

🍺

Brewed Insight: IPAM in AVNM isn’t flashy, but it solves a problem almost every serious Azure deployment hits eventually. The lack of centralised IP tracking was a blind spot – this fixes it, cleanly and natively. More importantly: it keeps networking out of Excel. That alone deserves a toast.

Learn More

IP Address Management with AVNM – Microsoft Docs
Official overview of IPAM features and capabilities inside Azure Virtual Network Manager
AVNM Overview
Starts from the top: what AVNM is, why it matters, and where IPAM fits in
Connectivity configurations in AVNM
Learn how to layer IPAM with custom connectivity across VNets
Bicep Templates for AVNM / IPAM
Full Bicep reference for deploying AVNM components

Azure Virtual Network Manager for Disaster Recovery

Tue, 29 Jul 2025 00:00:00 +1000

When a regional outage hits—or someone trips over a network cable in the wrong data centre your we need to enact our Disaster Recovery plan. If you don’t have one, get one.

AVNM doesn’t replace DR, but it can sure make it more resilient and repeatable.

This post explores how to design AVNM with disaster recovery in mind, covering regional network segmentation, active/passive VNets, and failover patterns that actually hold up under pressure.

What is Disaster Recovery (DR) in the context of AVNM?

In Azure, Disaster Recovery planning means replicating your workloads and network configurations across regions to maintain availability during outages. AVNM helps by centralising network topology and connectivity rules, allowing consistent failover designs across your environments.

AVNM doesn’t manage replication or data for that you need to look towards services like Azure Site Recovery or Azure Backup. But it is critical in:

Ensuring consistent network security rules across primary and secondary regions
Deploying connectivity rules (mesh, hub-spoke) as code
Reducing risk of drift between your recovery and production network topologies

In short: AVNM helps your failover network behave like your production network—without extra manual effort.

How It Works

AVNM lets you define network groups and configurations (connectivity and security rules) centrally. You can apply these across VNets within and across regions. AVNM’s strength in DR is its ability to:

Manage cross-region connectivity policies
Apply consistent NSGs and admin rules (via Security Admin Rules)
Integrate into CI/CD pipelines for automated, ring-fenced deployment

In disaster recovery, you typically:

Mirror your VNet topologies across regions
Use AVNM to apply the same connectivity/security configurations to both sides
Trigger failover and know that the secondary region behaves like production

Real-World Impact

Let’s say you run an internal app stack with:

Azure Firewall and monitoring in a shared services VNet
Web + API + SQL tiers split across VNets in a production region
A full mirror of the above in a failover region

Without AVNM:

You manage peering, security groups, and routing in both regions manually
Any deviations hurt when failover is needed

With AVNM:

You define once, apply to both
Your DR region becomes predictable, testable, and deployment-safe

Implementation Examples

Scenario: Active/Passive split across regions

You’ve got:

Primary in Australia East
Secondary in Australia Southeast

You’ve built matching VNets: prod-web, prod-api, prod-db in both regions. Traffic is normally served from the primary. Failover is DNS-based or routed via Azure Traffic Manager / Front Door.

AVNM Approach

Create a network group that includes both regions’ VNets
Set up a hub-and-spoke security config for each region
Apply the same configuration to both sets via AVNM
Use Policy/Tags to enforce DR region VNets are always included
(Advanced) Integrate with an automation pipeline to validate drift and deploy config updates

Azure Portal Steps

Go to AVNM in Portal
Create or select a Network Group

Use dynamic membership rules—example:

1
2
3


tag.region = australiaeast
or
tag.region = australiasoutheast

Define a Connectivity Configuration:
- Topology: Hub and Spoke
- Assign matching Hubs per region
- Add all VNets using dynamic rules
Define a Security Admin Rule Collection:
- Allow: L3 inbound between Trusted VNets (e.g., API -> DB)
- Deny: Internet inbound except Web zone

Bicep Example

In this example we are deploying two Virtual Networks in each Australia region connecting them using a Hub-n-Spoke topology and then applying security rules. Note that the example is missing the deployment scripts to deploy the configurations but you can get that from my previous posts.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258


@description('Location for all resources')
param location string = resourceGroup().location

@description('Configuration type to deploy')
param configType string = 'Connectivity'

// Create AU East Hub VNet
resource auEasthubVnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'MyHubVNet-AUEast'
 location: location
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.0.0.0/16'
 ]
 }
 }
 tags: {
 environment: 'HubNet'
 region: 'australiaeast'
 }
}

// Create Spoke VNets
resource auEastspokeVnet01 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'MySpokeVNet01-AUEast'
 location: location
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.1.0.0/16'
 ]
 }
 }
 tags: {
 environment: 'production'
 region: 'australiaeast'
 }
}

// Create AU Southeast Hub VNet
resource auSoutheastHubVnet 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'MyHubVNet-AUSouth'
 location: 'australiasoutheast'
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.10.0.0/16'
 ]
 }
 }
 tags: {
 environment: 'HubNet'
 region: 'australiasoutheast'
 }
}

// Create Spoke VNets
resource auSoutheastspokeVnet01 'Microsoft.Network/virtualNetworks@2024-07-01' = {
 name: 'MySpokeVNet01-AUSouth'
 location: 'australiasoutheast'
 properties: {
 addressSpace: {
 addressPrefixes: [
 '10.11.0.0/16'
 ]
 }
 }
 tags: {
 environment: 'production'
 region: 'australiasoutheast'
 }
}

// Create AVNM in each region
resource AUEastavnm 'Microsoft.Network/networkManagers@2024-07-01' = {
 name: 'mynetworkManager-AUEast'
 location: location
 properties: {
 networkManagerScopeAccesses: [
 configType
 ]
 networkManagerScopes: {
 subscriptions: [
 subscription().id
 ]
 }
 }
}

resource AUSouthavnm 'Microsoft.Network/networkManagers@2024-07-01' = {
 name: 'mynetworkManager-AUSouth'
 location: 'australiasoutheast'
 properties: {
 networkManagerScopeAccesses: [
 configType
 ]
 networkManagerScopes: {
 subscriptions: [
 subscription().id
 ]
 }
 }
}

// Create Network Groups
resource auEasthubGroup 'Microsoft.Network/networkManagers/networkGroups@2024-07-01' = {
 parent: AUEastavnm
 name: 'AUEast-HubGroup'
 properties: {
 description: 'AU East Hub VNet group'
 }
}

resource auSoutheasthubGroup 'Microsoft.Network/networkManagers/networkGroups@2024-07-01' = {
 parent: AUSouthavnm
 name: 'AUSouth-HubGroup'
 properties: {
 description: 'AU Southeast Hub VNet group'
 }
}

// Static Network Groups for Hubs
resource AUEastStaticNetworkGroupHub 'Microsoft.Network/networkManagers/networkGroups/staticMembers@2024-05-01' = {
 parent: auEasthubGroup
 name: 'AVNM-AUEast-HubGroup-Static'
 properties: {
 resourceId: auEasthubVnet.id
 }
}

resource AUSouthStaticNetworkGroupHub 'Microsoft.Network/networkManagers/networkGroups/staticMembers@2024-05-01' = {
 parent: auSoutheasthubGroup
 name: 'AVNM-AUSouth-HubGroup-Static'
 properties: {
 resourceId: auSoutheastHubVnet.id
 }
}

// Dynamic Network Groups for Spokes
resource auEastSpokeGroup 'Microsoft.Network/networkManagers/networkGroups@2024-07-01' = {
 parent: AUEastavnm
 name: 'AUEast-prod-vnets'
 properties: {
 description: 'Production VNets tagged environment=production & region=australiaeast'
 dynamicMembershipDefinition: {
 criteria: [
 {
 memberType: 'Microsoft.Network/virtualNetworks'
 field: 'tag.environment'
 operator: 'Equals'
 value: 'production'
 }
 {
 memberType: 'Microsoft.Network/virtualNetworks'
 field: 'tag.region'
 operator: 'Equals'
 value: 'australiaeast'
 }
 ]
 }
 }
}

// Dynamic Network Groups for Spokes
resource auSouthSpokeGroup 'Microsoft.Network/networkManagers/networkGroups@2024-07-01' = {
 parent: AUSouthavnm
 name: 'AUSouth-prod-vnets'
 properties: {
 description: 'Production VNets tagged environment=production & region=australiasoutheast'
 dynamicMembershipDefinition: {
 criteria: [
 {
 memberType: 'Microsoft.Network/virtualNetworks'
 field: 'tag.environment'
 operator: 'Equals'
 value: 'production'
 }
 {
 memberType: 'Microsoft.Network/virtualNetworks'
 field: 'tag.region'
 operator: 'Equals'
 value: 'australiasoutheast'
 }
 ]
 }
 }
}

// Create Azure Policy for dynamic network group
module avnmAUEastDynamicProductionNetworkGroup 'avnm-policy-networkgroup-aueast.bicep' = {
 scope: subscription()
 name: 'avnm-dynamic-production-aueast-network-group-policy'
 params: {
 networkManagerName: 'mynetworkManager-AUEast'
 }
 dependsOn: [
 auEasthubGroup
 ]
}

module avnmAUSouthDynamicProductionNetworkGroup 'avnm-policy-networkgroup-ausouth.bicep' = {
 scope: subscription()
 name: 'avnm-dynamic-production-ausouth-network-group-policy'
 params: {
 networkManagerName: 'mynetworkManager-AUSouth'
 }
 dependsOn: [
 auSoutheasthubGroup
 ]
}

// Connectivity Configuration (Hub-and-Spoke)
resource AUEastconnectivityConfig 'Microsoft.Network/networkManagers/connectivityConfigurations@2024-07-01' = {
 parent: AUEastavnm
 name: 'hubAndSpokeConfig'
 properties: {
 connectivityTopology: 'HubAndSpoke'
 hubs: [
 {
 resourceId: auEasthubVnet.id
 resourceType: 'Microsoft.Network/virtualNetworks'
 }
 ]
 appliesToGroups: [
 {
 groupConnectivity: 'None'
 networkGroupId: auEastSpokeGroup.id
 useHubGateway: 'True'
 isGlobal: 'False'
 }
 ]
 description: 'Hub-and-spoke connectivity'
 }
}

resource AUSouthconnectivityConfig 'Microsoft.Network/networkManagers/connectivityConfigurations@2024-07-01' = {
 parent: AUSouthavnm
 name: 'hubAndSpokeConfig'
 properties: {
 connectivityTopology: 'HubAndSpoke'
 hubs: [
 {
 resourceId: auSoutheastHubVnet.id
 resourceType: 'Microsoft.Network/virtualNetworks'
 }
 ]
 appliesToGroups: [
 {
 groupConnectivity: 'None'
 networkGroupId: auSouthSpokeGroup.id
 useHubGateway: 'True'
 isGlobal: 'False'
 }
 ]
 description: 'Hub-and-spoke connectivity'
 }
}

Gotchas & Edge Cases

Latency between regional hubs: Avoid cross-region mesh unless you’re really sure—firewall packet inspection adds rub.
Dynamic group membership: Based on tags or names—great until someone renames things.
NVA scenarios: Injected routes or third-party appliances must have mirrored configs too. AVNM won’t fix asymmetric routing hell.
Policy deployments: AVNM config changes can take minutes to fully propagate—be patient with failovers.

Best Practices

Align regional DR VNets with matching naming and tagging standards
Use dynamic network groups for easy inclusion of new VNets
Validate AVNM configuration in both regions as part of DR tests
Pair with Azure Policy to enforce required AVNM configuration
Version-control AVNM definitions via IaC (Bicep, Terraform)

🍺

Brewed Insight:

Too many DR setups assume “we’ll just replicate the app and connect stuff later”—but if your network isn’t aligned, failover equals facepalm. AVNM gets rid of tedious, error-prone per-region setups and gives you a DR network as predictable as a long black on Monday morning.

Don’t wait until the outage.

Learn More

Azure Virtual Network Manager in Enterprise Landing Zones

Thu, 24 Jul 2025 00:00:00 +1000

If you’ve ever tried wrangling networking in a landing zone deployment — half a dozen subscriptions, three environments, shared DNS, and a security team breathing down your neck — you already know: the pain’s real.

Enter Azure Virtual Network Manager (AVNM) — your new central control plane for enterprise-grade network governance.

Azure Landing Zones: A Quick Refresher

Azure Landing Zones (ALZ) are the enterprise implementation of Microsoft’s Cloud Adoption Framework (CAF). Think of them as blueprints for scaling cloud platforms in a secure-by-default, governed-by-design way.

Key components often include:

Hub-and-spoke network topologies
Central shared services (e.g. DNS, firewalls, logging)
CI/CD-delivered connectivity and policy
Split responsibilities between platform and application teams

But here’s the kicker — landing zones scale fast. And with speed comes complexity, especially in your network layer.

That’s where AVNM slips neatly into the picture.

Where AVNM Fits In

AVNM gives platform teams a way to:

Define topology once and apply it across subscriptions and environments
Centralise security enforcement without duplicating NSG rules
Control peering and rule scoping even in a multi-region, multi-team model
Simplify change audits all AVNM configs are declarative, tracked, and enforceable

Instead of spending hours scripting peerings and distributing “golden” NSGs via ARM or Bicep templates, you define:

Connectivity configurations for hub-and-spoke or mesh topologies
Security admin configurations for egress lockdowns, segmentation walls, etc.
Network groups scoped by tags to dynamically assign VNets to policies

AVNM as a Platform Service (in Your Org Chart)

Landing zones often divide responsibility like this:

Role	What They Deploy	What They Should Own in AVNM
Platform Team	Hub, firewalls, monitoring, base NSGs	AVNM resource + all topology/security configs
App Teams	Spokes (VNets), subnets, workloads	VNet deployment; inherit AVNM configs
Security Team	Logging, SIEM, network policy	Define security rule strategy, review rule collections

AVNM lets you enforce connectivity guardrails and baseline security — without stopping apps from shipping.

By deploying AVNM at the management group level, platform teams can apply topology + protections org-wide without taking away flexibility from application developers.

Network Group Strategy in Landing Zones

Your AVNM Network Groups become the key scoping unit for applying rules and peering policies.

Effective patterns include:

By environment:
Use tags like environment=dev, environment=prod
→ Useful for applying per-environment egress rules and segmenting tiers
By workload or platform zone:
Tags like app=billing, tier=data, zone=shared
→ Use this to isolate specific data-sensitive workloads
By function:
role=core or function=trusted-services
→ For shared DNS zones, Active Directory, or jump boxes

Combine this with Azure Policy and tags and you’ve got scalable, human-readable, code-driven scoping with dynamic membership baked in.

Real Enterprise Use Cases

1. Perimeter Guardrails for Every VNet

Stop egress to the internet across all VNets except what’s explicitly allowed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


resource DenyOutboundRule 'Microsoft.Network/networkManagers/securityAdminConfigurations/ruleCollections/rules@2024-05-01' = {
 parent: SecurityRuleCollection
 name: 'DenyAllOutbound'
 kind: 'Custom'
 properties: {
 description: 'Deny All outbound traffic'
 protocol: '*'
 direction: 'Outbound'
 sourcePortRanges: ['0-65535']
 destinations: [
 {
 addressPrefixType: 'IPPrefix'
 addressPrefix: '*'
 }
 ]
 destinationPortRanges: ['0-65535']
 access: 'Deny'
 priority: 100
 }
}

This rule lives in a Security Admin Configuration applied to a network group that matches all tagged VNets in dev and test environments. Simple, controlled, repeatable.

2. Hub-and-Spoke Topology as a Service

In your Bicep module:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@description('Location for all resources')
param location string = resourceGroup().location

@description('Name of the Network Manager')
param networkManagerName string = 'myNetworkManager'

resource avnm 'Microsoft.Network/networkManagers@2024-07-01' = {
 name: networkManagerName
 location: location
 properties: {
 networkManagerScopeAccesses: ['Connectivity']
 networkManagerScopes: {
 managementGroups: ['/providers/Microsoft.Management/managementGroups/mg-platform']
 }
 }
}

AVNM then auto-peers new spokes into the correct topology without scripts, with dynamic entitlement via tag-based Network Groups like zone=shared-hub or zone=app-spoke.

3. Zero Trust Segmentation Between App Tiers

Create network groups for each trust zone (e.g. tier=frontend, tier=backend)
Use admin rules to deny cross-tier traffic by default
Allow application-specific paths via NSGs or dedicated allow rules

This approach matches the CAF Zero Trust strategy and avoids lateral movement with a single policy.

4. Spoke Isolation + Shared Access

Apply connectivity config that links spokes to hub
Apply admin rule that denies spoke-to-spoke traffic
Hub implements central inspection/firewall/logging

This pattern’s critical in regulated industries and helps with:

Audit compliance
Network simplicity
Reduced blast radius

Monitoring and Azure Service Integration

AVNM plays nicely with the rest of the Azure stack:

NSGs & ASGs: Still valid — now layered beneath AVNM rules
Defender for Cloud: Reports on AVNM rule misalignments + security insights
Log Analytics: Use diagnostic settings on AVNM resources for audit trails
Azure Policy: Enforce tagging and AVNM config presence using policy-as-code

AVNM in ALZ: Topology Snapshot

%% AVNM in a Landing Zone Architecture graph TD MG[Management Group: Platform] --> AVNM(Azure Virtual Network Manager) AVNM --> NGProd[Network Group: Prod VNets] AVNM --> NGDev[Network Group: Dev VNets] AVNM --> AVNMRules(Security Admin + Conn Configs) subgraph Subscriptions HubSub(Hub Subscription) DevSub(Dev Subscription) ProdSub(Prod Subscription) HubVNet(Hub VNet) DevVNet(Dev VNet) ProdVNet(Prod VNet) end AVNMRules --> DevVNet AVNMRules --> ProdVNet HubVNet --> DevVNet HubVNet --> ProdVNet MG --> HubSub MG --> DevSub MG --> ProdSub

Best Practices

Deploy AVNM at the management group level for complete coverage
Use consistent tagging strategy to simplify group scoping
Document rule intention in Bicep descriptions or Git repositories
Delegate access clearly because AVNM config should be owned like a platform product
Start with ReadOnly mode when previewing admin rules impact

🍺

Brewed Insight:

Landing Zones without AVNM are like a good café with a terrible till — everything’s made with care, but no one’s quite sure who’s paid for what.

AVNM solves the governance gap between thoughtful architecture and consistent enforcement. Define your network policy once, encode it in infrastructure, and let dev teams focus on shipping — not debugging peerings from last sprint.

Golden topology. Guardrails enforced. Coffee not required (but strongly encouraged).