Managing on-premises servers centrally takes a lot of pressure off. That relief fades once you look at the security problems that show up when Azure Arc servers get treated like just another cloud VM. I keep running into technically solid deployments where someone took the easy route with identities, role assignments or network exposure. Everything works fine, right up to the point where it doesn't. With Arc in particular, small details in onboarding, agent controls and privileged access decide whether you end up with a well-protected hybrid estate or a wide-open gap in your Tier 0 perimeter.

A dedicated Service Principal with just enough rights handles Arc onboarding

I often find customers onboarding Arc servers with Contributor or even Owner rights on the subscription. That is far more than the job needs, and it's a security risk. What I do instead is create a dedicated Service Principal, give it only the Azure Connected Machine Onboarding role, and scope it tightly to the resource group or private link scope where the Arc servers should end up. Microsoft Learn documents this well. It works for Windows and Linux alike and fits nicely into automated scripts for mass deployments.

Tip from the field: Don't let onboarding scripts store secrets in plaintext. Use certificate-based authentication where you can, or managed identities if you're onboarding Azure VMs to Arc.

Private Link Scope keeps Arc management traffic private

Setting up a Private Link Scope makes a big difference for Arc server security. All Arc management traffic, including Policy, Defender for Servers, Update Manager and extension deployment, then goes through private endpoints. That cuts the attack surface considerably, especially for servers sitting in sensitive internal networks. DNS for arc.private.azure.com is where people tend to trip up, though. You have to update your internal DNS so the machines resolve the private endpoints correctly. The official security overview lists what's required, and I'd get this right from day one.

An extension allowlist hardens what the Arc agent is allowed to run

This risk gets missed a lot. Every Azure Arc extension runs as SYSTEM (or root) on the target machine. In large environments with delegated RBAC, someone with the wrong rights could deploy malicious code, abuse credentials or switch off monitoring. For that reason I always recommend an extension allowlist on production Arc servers. It's simple to set up and very effective:

# On the Arc server, as Administrator (Windows Terminal or Bash)
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor,Microsoft.Azure.Security.Monitor,Microsoft.Azure.UpdateManagement,Microsoft.Azure.MachineConfig"

After that, Arc can only deploy these extensions (monitoring, Defender, Update Manager and machine configuration). A major path for lateral movement or privilege escalation is closed.

Azure Arc servers now cover patching, security and compliance

The Azure Arc management stack has matured a lot. I rarely see customers still running patch jobs through old Automation Accounts, because Azure Update Manager handles Arc servers natively. Security posture and protection come in through Defender for Servers, and Azure Machine Configuration enforces OS-level compliance without domain GPOs. You can also open a secure SSH session to Arc servers straight from the Azure portal. No exposed ports and no juggling jump hosts, which helps a lot in segmented DMZs or regulated networks.

The diagram below shows how these components fit together into a secure management path:

flowchart TD
    OnPrem["On-prem server"] --> Agent["Arc agent"]
    Agent --> ExtAllow["Allowlist extensions"]
    Agent --> PrivateLink["Private Link scope"]
    Agent --> Azure["Azure management services"]
    Azure --> Update["Update Manager"]
    Azure --> Defender["Defender for Servers"]
    Azure --> Config["Machine configuration"]
    Azure --> SSH["SSH via Arc"]

Figure: Azure Arc servers, architecture and security controls

Windows Server 2025 brings pay-as-you-go and ESUs through Arc

Windows Server 2025 makes Arc even more relevant. With pay-as-you-go licensing and built-in ESU management (for legacy Windows Server versions), you can activate and patch servers without dealing with local MAK/volume keys or manual update workarounds. For older Windows Server 2012 R2 or 2016 machines that have to stay around for compliance reasons, that's real progress. It only holds up if the Arc onboarding and role assignments are locked down, though. No shared Service Principals and no interactive accounts.

I've written up the ESU workflow via Arc and what I learned along the way here: Windows Server 2012 ESU through Azure Arc as a simpler update bridge.

Arc admin rights count as Tier 0 privileges

I make this point in every workshop. Anyone with admin permissions on Arc servers can deploy extensions and policies that run as SYSTEM/root on every managed server. That's Tier 0 power, on the same level as Domain Admins or Entra Global Admins. Keep that access under tight control. Use separate accounts, enforce MFA, give serious thought to Privileged Identity Management for just-in-time elevation, and review RBAC assignments regularly. If you overlook this, your whole hybrid infrastructure is exposed to privilege escalation or ransomware campaigns.

Azure Arc servers are an excellent bridge between on-prem and cloud management, as long as you give identities, network boundaries and agent controls the care they need. Skip the shortcuts and your Tier 0 will be much better off.