Azure Arc Security Guide: Identity, Extensions, Lockdown

Azure Arc turns every on-premises or other-cloud server it onboards into an Azure resource, which means anyone with the right Azure role can now run code on that server as Local System or root. That is the point of Arc, and it is also the risk: subscription owners become local administrators of domain controllers, payment servers and file servers that were never meant to be managed from the cloud. This guide covers Arc-enabled servers (the Connected Machine agent), not Arc-enabled Kubernetes or data services. It explains the agent's identity model, the roles that matter, the onboarding service principal, the local controls that Azure administrators cannot override, and what to log. It is written for cloud, Windows and Linux platform engineers and for the security team that has to sign off Arc for Tier 0 servers. For Azure-wide controls, read the Microsoft Azure Security Guide first.

Key takeaways

Azure control equals local control. The extension manager and Run Command execute as Local System on Windows and root on Linux, so Azure Connected Machine Resource Administrator, Contributor and Owner on the scope are effectively local admin rights.
Every Arc server gets a managed identity. The agent exposes a local token endpoint on port 40342; any process that can read the challenge token file can obtain Entra tokens for the machine's system-assigned identity.
Local agent settings beat cloud permissions. azcmagent config allowlists, monitor mode and disabled guest configuration are set on the server and cannot be overridden by an Azure Owner or Global Administrator.
The onboarding service principal is a standing credential. Scope it with Azure Connected Machine Onboarding only, keep the secret short-lived and never leave it in deployment scripts or golden images.
Put sensitive servers in a dedicated subscription. Microsoft's own guidance for Tier 0 assets is a separate subscription with as few persistent administrators as possible, and a review of policies inherited from parent management groups.

How identity and access work in Azure Arc

The Azure Connected Machine agent has three main services and a proxy. Their run-as accounts decide what a compromise of each one is worth.

Component (Windows service / Linux daemon)	Runs as	What it does	Security implication
HIMDS: `himds` / `himdsd.service`	`NT SERVICE\himds` virtual account / `himds` user	Registration, heartbeats, local REST API, managed identity tokens	Unprivileged by design; needs "Log on as a service", which Group Policy may strip
Extension manager: `ExtensionService` / `extd.service`	Local System / root	Installs, updates and removes VM extensions, including Custom Script and Run Command handlers	Remote code execution path from Azure; restrict with an allowlist or disable
Machine configuration: `GCArcService` / `gcad.service`	Local System / root	Evaluates and, in enforce mode, remediates Azure machine configuration (guest configuration) policies written in PowerShell DSC	A custom policy can change local settings; disable where not needed
Azure Arc Proxy	Network Service / `arcproxy`	Routes agent and extension traffic, including through Arc gateway	Starts by default since agent 1.51

The machine's managed identity

Endpoint: the agent sets IDENTITY_ENDPOINT=http://localhost:40342/metadata/identity/oauth2/token and IMDS_ENDPOINT=http://localhost:40342. On Linux these are written to /lib/systemd/system.conf.d/azcmagent.conf.
Challenge token: an unauthenticated request returns a WWW-Authenticate: Basic realm=<path> header pointing to a secret file. The caller must read that file and send its contents back. This is what stops an arbitrary local process from requesting tokens, and it differs from the Azure VM IMDS, which has no file check.
Who can read the file: on Windows, members of the local Administrators group or the Hybrid agent extension applications group; on Linux, members of the himds group (root can always read it). Membership of those groups is therefore equivalent to holding the machine's Azure credential.
Agent identity: the agent uses local system-managed identities, not domain or user accounts, and this is not configurable. There is no service account password to rotate on the server itself.

Treat the system-assigned identity like any other workload identity: grant it only the Azure roles a workload on that server genuinely needs (reading a Key Vault secret, writing to a storage account), never broad roles at subscription scope. An attacker with local admin on the server can use those roles from anywhere they can reach Entra ID, which maps to ATT&CK T1552.005 Cloud Instance Metadata API followed by T1078.004 Cloud Accounts. See the Azure Managed Identities Security Guide.

Admin roles and privileged access

Arc does not add a separate permission model: Azure RBAC on the Microsoft.HybridCompute/machines resource and its parent scopes decides who can act on the server. Azure is the source of truth, so RBAC and Azure Policy are evaluated before a change reaches the machine.

Role or permission	What it allows on an Arc server	Effective local impact	Who should hold it
Azure Connected Machine Onboarding	Connect machines to Arc with `azcmagent connect`	None after onboarding, but can register rogue machines into your scope	Onboarding service principal only, at resource group scope
Azure Connected Machine Resource Administrator	Read, modify and delete machines; `Microsoft.HybridCompute/machines/runCommands/write`	Run Command and extensions, so code as Local System or root	A small server operations group, ideally via just-in-time activation
Contributor or Owner on the scope	Everything above, plus SSH connectivity endpoint use	Local admin equivalent; Owner can also grant roles	Break-glass and platform owners only
Virtual Machine Administrator Login / Virtual Machine User Login	Entra ID sign-in over SSH (Linux, via the `AADSSHLoginForLinux` extension)	Interactive admin or standard shell	Named administrators, eligible rather than permanent
Reader	List machines and Run Command history (`runCommands/read`)	None, but exposes inventory and installed software	Operations and audit teams
Policy assignment rights at parent management groups	Deploy extensions or machine configuration through Azure Policy at scale	Fleet-wide code execution where local controls allow it	Platform governance team under change control

Separate Tier 0: domain controllers, PKI and identity servers onboarded to Arc inherit every role assignment above them. Microsoft recommends a dedicated subscription with as few persistent administrators as possible, because subscription and management group administrators are effectively local admins on those servers.
Entra SSH is deliberately separate: Owner or Contributor lets a user use SSH through the Arc connectivity endpoint, but Entra sign-in needs the Virtual Machine Administrator Login or User Login role. Use Privileged Identity Management for both, assigned at resource group or subscription scope rather than per machine. See the JIT Access Guide.
Run Command is not in the portal: it is available through CLI, PowerShell and REST only, so portal-centric reviews miss it. It can run as a different local user through RunAsUser and RunAsPassword, which puts a local password in an Azure API call.
Owner rights over the Entra tenant matter too: anyone who can add credentials to the onboarding application or assign roles can rebuild the access path. See the Azure RBAC and Service Principals Guide.

Integrations, API tokens and service accounts

The onboarding service principal

At-scale onboarding uses a service principal passed to azcmagent connect with service-principal-id and service-principal-secret. Microsoft states it is used only during onboarding, so it should not outlive the onboarding wave.

Role: assign Azure Connected Machine Onboarding, not Contributor, even though Contributor on the resource group also works.
Scope: one resource group per onboarding wave or environment. A subscription-wide onboarding principal lets anyone holding the secret register machines next to your production servers.
Secret handling: pick the shortest validity the rollout allows, inject it at run time from a secrets store or deployment tool, and remove it from scripts, Group Policy startup scripts, Ansible variables and VM templates afterwards. A secret in a golden image is a credential in every copy. See the Azure Entra Client Secrets Security Guide.
Retire it: delete the secret, or the whole app registration, when the wave ends. Onboarding a new machine later can use a fresh secret.

Extensions and the credentials they carry

Protected settings: extension protected settings are not persisted in Azure and are encrypted at rest on the machine; regular settings are stored in Azure and readable by anyone with read access. Never put secrets in regular settings.
Package integrity: before running an extension the extension manager checks the package against a separately downloaded, digitally signed catalog and aborts on mismatch. Packages come from *.blob.core.windows.net unless private endpoints are used.
Run Command output: output and error streams can be written to append blobs through SAS URIs with read, append, create and write permissions. Scope and expire those SAS tokens tightly. See the Azure SAS Tokens Security Guide.
Workload use of the managed identity: applications on the server that need Azure resources should use the Arc managed identity rather than a stored client secret, which removes a secret but adds the group membership checks described above.

Logging and detection

Arc gives you two log planes: the Azure Activity Log for every control-plane action, and local agent logs on the server. Both are needed because local changes to azcmagent config never appear in Azure.

Source	Location or operation	What to alert on
Azure Activity Log	`Microsoft.HybridCompute/machines/extensions/write`	Custom Script, Run Command handler or unknown publisher installed on a sensitive server
Azure Activity Log	`Microsoft.HybridCompute/machines/runCommands/write`	Any Run Command on Tier 0; any outside a change window
Azure Activity Log	`Microsoft.Authorization/roleAssignments/write` on Arc scopes	New Resource Administrator, Contributor or VM Login assignments
Azure Activity Log	`Microsoft.HybridConnectivity/endpoints` writes	SSH connectivity endpoint created or service configuration added
Resource Health	Heartbeat missing for more than 15 minutes	Agent stopped, network blocked or server offline
Agent log	`himds.log` in `%ProgramData%\AzureConnectedMachineAgent\Log` or `/var/opt/azcmagent/log`	Identity and heartbeat errors, repeated token requests
Agent log	`azcmagent.log` (same folder)	Local `azcmagent config set` or `disconnect` commands
Extension log	`%ProgramData%\GuestConfig\ext_mgr_logs\gc_ext.log` or `/var/lib/GuestConfig/ext_mgr_logs`	Install, update and remove events, blocked extensions
Operating system	Windows Security log membership changes, Linux auditd on `/etc/group`	Additions to `Hybrid agent extension applications` or `himds`

Forward the Activity Log to your SIEM through diagnostic settings and collect the agent log folders with your endpoint or log agent. Relevant ATT&CK techniques are T1651 Cloud Administration Command (Run Command and Custom Script used for execution), T1098 Account Manipulation (role assignments) and T1021.004 SSH. See the Cloud Logging and Audit Trail Guide.

Metrics that show it is working

Locked-down coverage: percentage of Tier 0 and regulated Arc servers with an extensions allowlist or monitor mode set (target 100 percent).
Standing privilege: number of permanent Resource Administrator, Contributor and Owner assignments on Arc scopes (trend down, PIM eligible instead).
Unplanned execution: Run Command and Custom Script operations without a change reference per month (target zero on sensitive servers).
Agent currency: percentage of agents within one release of current, from Azure Advisor or Resource Graph.
Onboarding credential age: days since the onboarding secret was created, and number of live onboarding secrets (target zero between waves).

Hardening baseline

Local agent controls

These settings are made on the server with azcmagent config set from an elevated console or with sudo. Microsoft documents that allow and block lists cannot be overridden by Owner or Global Administrator in Azure, but anyone with local admin or root can change them.

Setting	Effect	When to use
`extensions.allowlist "Publisher/Type,..."`	Only listed extensions can be installed, updated or upgraded; delete is always allowed	Default for sensitive servers; blocks future extensions too
`extensions.blocklist "..."`	Everything except listed extensions is allowed	Weaker fallback, for example blocking `Microsoft.Compute/CustomScriptExtension` and the RunCommandHandler types
`extensions.allowlist "Allow/None"`	Extension manager runs but no extensions are allowed	Servers onboarded only for ESU or inventory
`config.mode monitor`	Only Microsoft-maintained monitoring and security extensions; guest configuration disabled; lists cannot be edited	Simplest lockdown where Azure Monitor Agent and Defender are all you need
`guestconfiguration.enabled false`	Disables machine configuration policies	Unless Defender for Cloud regulatory compliance needs it
`extensions.enabled false`	Disables the extension manager	No extensions at all; remove installed ones first
`incomingconnections.enabled false`	Disables incoming remote access, including SSH through Arc	Servers that must never be reached through Azure

Configuring a list does not remove extensions already installed: delete them from Azure first. Lists can also be pushed with Azure Policy, but whoever can edit those policy assignments can then remove the protection, so for Tier 0 set them locally through your existing build process.

Network and platform

Outbound only: the agent connects outbound on TCP 443 (plus HTTP 80 to www.microsoft.com/pkiops/certs for ESU). No inbound ports or public IPs are required.
Private Link: an Azure Arc private link scope makes *.his.arc.azure.com and *.guestconfiguration.azure.com private; Entra ID, notification and download endpoints stay public.
TLS: require TLS 1.2 or 1.3, and allow the full AzureArcInfrastructure service tag rather than regional subsets.
Patching: keep the agent current through Azure Advisor alerts or agent auto-update, and patch the OS through your normal process or Azure Update Manager. See the Patch Management Guide.
Protect group membership: restrict and monitor the Hybrid agent extension applications and himds groups, and make sure Group Policy keeps "Log on as a service" for NT SERVICE\himds.

Phased rollout

Design scopes first: create the subscriptions and resource groups (Tier 0 separate), the onboarding principal per group and the PIM-eligible operator roles before onboarding a single server.
Decide the lockdown profile per tier: monitor mode or a strict allowlist for Tier 0 and regulated servers, a broader allowlist for general servers, full mode only where operators need Run Command.
Pilot: Microsoft suggests a pilot of at least 30 days on non-critical machines. Apply the local settings at install time in the same script that runs azcmagent connect, then confirm with azcmagent config list.
Test the controls: from Azure, attempt a Custom Script install on a locked server and confirm it is blocked and logged in gc_ext.log.
Onboard in waves: rotate or delete the onboarding secret after each wave and check Resource Graph for machines in unexpected resource groups.
Roll back: azcmagent config set config.mode full, clearing the list or azcmagent disconnect reverses the change on a server; remove the Azure resource if the machine is disconnected offline.

Decision guidance

Monitor mode vs allowlist: monitor mode is easiest and Microsoft maintains the list, but you cannot add your own extensions. Choose an allowlist when you need, for example, Entra SSH login or a specific third-party agent.
Arc for Tier 0 at all: if you cannot isolate the subscription and keep standing admins near zero, consider not onboarding domain controllers, or onboarding them in monitor mode only for Defender and logging.
Small vs large estates: a small organisation can run one dedicated resource group per tier and local scripts; a large one should drive the settings from configuration management and use Azure Policy only for non-Tier 0 fleets.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Least privilege on Arc scopes	AC-6, AC-2	PR.AA-05	6 Access Control Management	A.8.2 Privileged access rights
Extension allowlist and disabled features	CM-7, CM-6	PR.PS-01	4 Secure Configuration	A.8.9 Configuration management
Onboarding secret and managed identity	IA-5	PR.AA-01	5 Account Management	A.5.17 Authentication information
Remote access through Arc SSH	AC-17	PR.AA-05	6 Access Control Management	A.8.5 Secure authentication
Activity Log and agent logs	AU-2, AU-6	DE.CM-09	8 Audit Log Management	A.8.15 Logging
Agent and OS updates	SI-2	PR.PS-01	7 Continuous Vulnerability Management	A.8.8 Management of technical vulnerabilities

Common misconfigurations

Domain controllers in a shared subscription: every Owner and Contributor of a busy application subscription silently becomes able to run code on the DCs. Isolate Tier 0 or keep it off Arc.
No local lockdown at all: with neither list configured every extension is allowed, so Custom Script Extension and Run Command are open to anyone holding Resource Administrator.
Lists pushed only by Azure Policy: convenient, but a compromised policy administrator can remove them fleet-wide. Set Tier 0 lists locally.
Onboarding secret left in the script: install scripts copied to file shares, Git repositories or images keep a working Azure credential long after onboarding. Delete the secret after each wave and scan for it.
Over-privileged machine identity: granting the server's system-assigned identity Contributor at subscription scope turns any local admin compromise into a cloud compromise.
Uncontrolled extension group membership: adding service accounts to Hybrid agent extension applications or himds to "make the app work" hands them the machine's Azure token.
Stale agents: agents never updated miss security fixes. Track version through Advisor and Resource Graph.

Practitioner checklist

Place Tier 0 Arc servers in a dedicated subscription with near-zero standing administrators and review inherited management group policies.
Assign Azure Connected Machine Onboarding to a per-wave service principal at resource group scope and delete its secret after the wave.
Set config.mode monitor or an extensions.allowlist locally on every sensitive server and verify with azcmagent config list.
Disable guest configuration and incoming connections where they are not used.
Make Resource Administrator, Contributor and VM Login roles PIM eligible rather than permanent.
Grant each machine's managed identity only the narrow roles its workloads need.
Restrict and alert on membership of Hybrid agent extension applications and himds.
Alert on extension writes, Run Command writes and role assignments on Arc scopes, and collect himds.log, azcmagent.log and gc_ext.log.
Use an Arc private link scope where policy requires private paths and allow the full AzureArcInfrastructure service tag.
Track agent version and heartbeat health, with a 15 minute missing-heartbeat alert.

Azure Arc Security Guide: Hybrid Server Identity, Extensions and Lockdown