Onboarding a server to Arc is presented as an install: run a script, watch a green check appear in the portal, move on. Treating it that way is the first mistake, because the script does not just register a machine. It installs an agent that can run code on that server as its most privileged account, and it hands the authority to do so to whoever holds the right role in Azure. Onboarding is a trust decision wearing the costume of a setup step, and the two questions that actually matter, what you are granting and how the connection is secured, are the ones the quickstart never makes you answer.
What the agent actually is
The Connected Machine agent is not one service, it is a small cluster of them, and knowing the parts changes how you reason about it. There is the hybrid instance metadata service, which owns the connection to Azure and holds the machine’s identity, exposing a local endpoint that anything on the box can ask for a token. There is the machine configuration agent, the component that evaluates and enforces policy inside the guest. There is the extension manager, which installs, updates, and removes the extensions that do the actual work. And since a recent release there is a proxy component, enabled by default, that sits in front of all of it and decides how traffic leaves the machine. When the agent connects, Azure mints the server a system-assigned managed identity and projects it into Resource Manager as a resource of its own. From that moment the server has an identity Azure trusts and a management surface Azure can drive, and both of those are the point of the exercise and the risk of it.
The grant you are actually making
Here is the part to be unsentimental about. The extension manager runs as SYSTEM on Windows and as root on Linux, and it installs whatever extension its Azure resource is told to install. That means anyone who can write an extension to the machine’s resource can execute arbitrary code on the server as its highest-privileged account. Onboarding is, stated plainly, a grant of remote code execution to a set of Azure principals. This is not a criticism of Arc; it is the nature of any cloud management agent, and it is exactly what makes the agent useful. But it reframes the resource group. A resource group full of Arc machines is not a folder, it is a blast radius, and the people with write access to it are effectively local administrators of every server inside. Design the subscription and resource-group layout as an RBAC and operational scope first and an organizational convenience second. Be precise about what that scope buys you: assigned narrowly it limits how far a single careless or compromised assignment reaches, but role assignments made at the subscription or management group above it inherit straight into it, so it bounds administration rather than isolating it. A tight resource group with loose inheritance above it is a boundary on paper only.
A resource group full of Arc machines is not a folder. It is a blast radius, and write access to it is local administrator on every server inside.
One default deserves a hard look before you deploy at scale. On Windows Server 2022 and 2025 the in-box onboarding wizard, the one that puts an Arc icon in the system tray, is present and enabled out of the box. It exists to make a single-server onboarding pleasant, and it does, but it also means any local administrator can interactively bind that server into some Azure tenant of their choosing. In an environment where tenancy is something you control deliberately, that convenience is a liability, and the right move is to strip the feature from the build image and rely on governed, at-scale onboarding instead. Convenience defaults and control requirements point in opposite directions here, and you have to decide which one wins in your build.
Connecting at scale without scattering secrets
Past a handful of machines you onboard with a service principal, and Microsoft provides a purpose-built role for exactly this: the Azure Connected Machine Onboarding role, which can create machine resources but cannot manage them afterward. Managing them is a separate, higher role. That split is deliberate and worth respecting, because the onboarding identity is the one you are about to distribute widely, and you want its power to be as close to nothing as the task allows. The honest weakness of the model is that the generated onboarding script carries the service principal secret in plain text, and you are about to push that script to every server through Group Policy, Configuration Manager, or Ansible. Microsoft’s mitigation is not that the secret is protected, because it is not. The mitigation is that the role is nearly powerless: if that secret leaks, the worst an attacker does is create junk machine resources in your resource group, not run code on your fleet. That reassurance holds only if you actually used the Onboarding role and scoped it tightly. Reach for Contributor because it was faster, and you have handed out the keys to the estate in a text file.
Give the secret a short expiry, scope the role to the narrowest resource group that works, and treat the onboarding credential as something you rotate on a schedule rather than mint once and forget. The blast radius of the onboarding path is a design choice, and the defaults do not make it for you.
The network path is moving under you
The connectivity story has changed enough in the last year that stale assumptions will bite. The baseline has always been outbound over 443 to a list of endpoints, and that list is longer than people expect and occasionally grows: a new front-door service tag became required in the spring of 2026, and the agent now expects a modern TLS cipher suite to be available and, as of a 2026 agent update, validates the negotiated suite so a mismatch surfaces plainly rather than failing silently. That requirement is the one that catches mature environments. A TLS-inspecting proxy that terminates and re-signs the agent’s traffic with anything less than the modern suites will break the connection, and a forthcoming change will make the agent reject certificates with non-compliant serial numbers outright. If your egress path runs through deep inspection, the Arc agent is a workload you must explicitly exempt, not one you can quietly proxy like a browser.
Two newer options change the shape of the problem rather than just the endpoint list. The Arc gateway, now generally available, collapses that sprawling allowlist down to roughly seven endpoints funneled through a single managed front door, which is a real simplification for a firewall team. It is not total, because monitoring, update, and Defender traffic still leaves around the gateway and needs its own allowances, and the gateway endpoint itself must be exempted from TLS inspection. Private Link is the other option, and it is the one most often oversold. It brings the Arc service endpoints inside your private network, but Entra sign-in, Resource Manager, and the agent package downloads still traverse the public internet. Pitching Private Link as no internet exposure is simply wrong, and a security review will find the gap. Pick the connectivity model as a deliberate design decision with its seams understood, not as a checkbox that promises more isolation than it delivers.
The veto the server keeps
Against all of that cloud authority, the machine retains one control that Azure cannot take from it. Through the agent’s local configuration you can restrict which extensions are permitted, block specific ones, disable the extension manager entirely, or run the agent in a monitor-only mode that allows nothing but Microsoft-managed tooling and turns off remote access and in-guest policy. This is a genuine local veto, and the documentation is blunt that no one in Azure, not an Owner and not a Global Administrator, can override it. The catch is symmetrical and important: because it is local, Azure also cannot read it or attest to it. You cannot look in the portal and know which of your servers have locked their extension surface. If that control matters to your threat model, and on a server that hosts something sensitive it should, you have to set it and enforce it the way you enforce any other host hardening, through configuration management, or it drifts silently and you will not see the drift from the cloud.
The lifecycle you inherit
Onboarding is the start of an operational relationship, and two of its rules surprise people later. The agent is supported only within about a year of its release, which turns agent currency into a standing maintenance task rather than a one-time install, and while automatic upgrade exists it is still a preview feature you opt into rather than a default you can lean on. The other rule is the one that causes real incidents: disconnecting the agent deletes the Azure resource, while deleting the resource in the portal without disconnecting leaves a live, orphaned agent on the server still trying to phone home. And a machine that simply goes quiet for long enough passes from disconnected into an expired state that an administrator has to clear by hand. None of this is hard, but all of it is the kind of thing that only hurts if you learned it during an outage instead of before one.
From decision to build
That is the architecture of onboarding: a real grant of authority, a network path with seams, a local veto you have to choose to use, and a lifecycle with a few sharp edges. The companion build sheet takes it from here and stands the thing up, from the onboarding service principal and its role through the connectivity choice to the verification that a machine is genuinely connected and reporting. After that we stop onboarding servers and start managing them, beginning with the piece everyone wants the answer to first: whether Azure Policy and machine configuration really are the replacement for Group Policy, and where that claim quietly breaks.
Azure Arc
‹ Previous: [ARC 1] Azure Arc: A Cloud Management Plane for Servers Anywhere
Next: [ARC 2.1] Build Sheet: Onboarding at Scale ›
