Azure Arc puts your physical and on-premises virtual servers under the cloud control plane, so you can patch, monitor and apply policy from one place. It also means a role assignment in your tenant can execute commands on a server sitting in your building, with the highest privileges that server offers. That is the trade, and it deserves a deliberate decision rather than a default one.
What the agent can do
The connected machine agent runs as a privileged service and accepts instructions from the platform. Extensions install software, run scripts and deploy monitoring, and the run command capability executes arbitrary commands as root or SYSTEM. That is the intended functionality and it is also a complete remote execution path. Anyone able to invoke those operations against a machine resource holds administrative control of the underlying server, no matter what your domain permissions say. The NCSC’s guidance on preventing lateral movement is relevant here in an unusual direction, because movement now runs from the cloud inward.
See also: Aligning Technology With Business Success
The permissions that matter
Look at who holds Contributor or the connected machine administrator roles at subscription or resource group scope, since both allow extension deployment. Look at the onboarding identity as well, because the service principal used to register machines is often granted broadly and stored in a script on a file share. Then check whether these roles are permanent rather than eligible through privileged identity management. In most tenants the list of people who can run a command on every server turns out to be longer than the list of domain administrators, which is rarely what anyone intended.
“Ask your infrastructure team to demonstrate running a command on an on-premises server from the Azure portal. Watch the faces of the people who thought the cloud tenant and the server estate were separate. That demonstration does more for your privileged access programme than any policy document, because it makes the connection concrete.”
William Fieldhouse, Director, Aardwolf Security Ltd
Getting the benefits without the exposure
The capability is genuinely useful, so constrain it rather than avoiding it. Make the roles that can deploy extensions eligible rather than permanent, with approval and a short activation window. Use policy to allow only the extensions you actually deploy, which blocks an attacker from installing their own. Log and alert on every run command execution, since legitimate use is rare and predictable in most estates. Separate resource groups by sensitivity so a role granted for the general server estate does not extend to domain controllers or payment systems.
Testing both sides of the boundary
Assess it as one system, because attackers will. Azure and hybrid penetration testing covers the tenant permissions, the onboarding identity and whether extension deployment can be reached from a low privilege position. An internal network security test covers the other direction, since an attacker on the internal network who compromises the agent’s host may be able to reach cloud resources through the machine identity. Booking only one of the two leaves the interesting half of the attack path untested.
Frequently asked questions about Azure Arc
These questions come up whenever hybrid management is being planned.
Does Arc open inbound ports?
No. The agent connects outbound over HTTPS to a defined set of endpoints, so there is no listening service to expose. The risk is not network exposure, it is the authority the control plane holds over the machine.
Should domain controllers be onboarded?
Only with careful thought and separate scoping. Bringing a tier zero system under a control plane managed by cloud roles merges two administrative tiers, so if you do it, treat the relevant Azure roles as tier zero as well.
