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. Microsoft also expects modern TLS cipher suites on Windows. Agent versions 1.56 through 1.63 enforced that hard enough to drop connections on hardened builds, and 1.64 backed the enforcement out, but the suites remain the documented requirement and azcmagent check now tests for them. If your baseline trims the cipher list, put the four suites Microsoft names back before you onboard rather than finding out from a support case. A TLS-inspecting proxy is less of a problem than people expect. The agent itself does not pin certificates, so it keeps working through inspection provided the server trusts the inspecting CA. What breaks is the server that has never been given that CA, the handful of extensions that do pin, and the Arc gateway endpoint, which Microsoft tells you to exempt. If your egress runs through deep inspection, push the inspection root to every server before you onboard, and plan exemptions per extension rather than for the agent as a whole. From February 2027 the agent will reject any certificate with a negative serial number, which is worth checking against your inspection proxy’s CA now rather than in February.
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 that the control runs one way. Azure can see it, because the agent reports its configuration mode, allowlist, blocklist and guest configuration state back onto the machine resource, and you can query that across the fleet. Azure cannot set it, change it, or enforce it. If that control matters to your threat model, and on a server that hosts something sensitive it should, you set it through configuration management like any other host hardening and use the reported state in Azure to catch drift.
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 ›
